You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@click.apache.org by "Bob Schellink (JIRA)" <ji...@apache.org> on 2009/06/02 17:45:07 UTC
[jira] Created: (CLK-557) PerformanceFilter applied to JSP pages
does not always return gzip response header
PerformanceFilter applied to JSP pages does not always return gzip response header
----------------------------------------------------------------------------------
Key: CLK-557
URL: https://issues.apache.org/jira/browse/CLK-557
Project: Click
Issue Type: Bug
Reporter: Bob Schellink
Assignee: Bob Schellink
Priority: Blocker
When including JSP pages it seems there are conditions under which the gzip header is not returned to the browser. Thus the raw bytes are displayed.
More strange is that the issue arise only when the size of the Page exceeds a certain threshold. This threshold does not seem to be related to the PerformanceFilter Gzip threshold of 384 bytes though.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (CLK-557) PerformanceFilter applied to JSP
pages does not always return gzip response header
Posted by Malcolm Edgar <ma...@gmail.com>.
Wow that is interesting. Does Spring Security fix this issue? Do you
want me to give this a try?
regards Malcolm Edgar
On Wed, Jun 3, 2009 at 3:27 AM, Bob Schellink (JIRA) <ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/CLK-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715598#action_12715598 ]
>
> Bob Schellink commented on CLK-557:
> -----------------------------------
>
> Turns out to be Acegi related. If I comment the filter out things go back to normal. Will try and figure out what Acegi is doing because it seems to remove the Content-Encoding header.
>
> We should probably use Spring security instead as that seems to be the recommended library?
>
>> PerformanceFilter applied to JSP pages does not always return gzip response header
>> ----------------------------------------------------------------------------------
>>
>> Key: CLK-557
>> URL: https://issues.apache.org/jira/browse/CLK-557
>> Project: Click
>> Issue Type: Bug
>> Reporter: Bob Schellink
>> Assignee: Bob Schellink
>> Priority: Blocker
>>
>> When including JSP pages it seems there are conditions under which the gzip header is not returned to the browser. Thus the raw bytes are displayed.
>> More strange is that the issue arise only when the size of the Page exceeds a certain threshold. This threshold does not seem to be related to the PerformanceFilter Gzip threshold of 384 bytes though.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
[jira] Commented: (CLK-557) PerformanceFilter applied to JSP pages
does not always return gzip response header
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715934#action_12715934 ]
Malcolm Edgar commented on CLK-557:
-----------------------------------
Have checked in a work around in Click Examples to only filter the ACEGI examples. I haven't tried the Spring Security yet.
> PerformanceFilter applied to JSP pages does not always return gzip response header
> ----------------------------------------------------------------------------------
>
> Key: CLK-557
> URL: https://issues.apache.org/jira/browse/CLK-557
> Project: Click
> Issue Type: Bug
> Reporter: Bob Schellink
> Assignee: Bob Schellink
> Priority: Blocker
>
> When including JSP pages it seems there are conditions under which the gzip header is not returned to the browser. Thus the raw bytes are displayed.
> More strange is that the issue arise only when the size of the Page exceeds a certain threshold. This threshold does not seem to be related to the PerformanceFilter Gzip threshold of 384 bytes though.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CLK-557) PerformanceFilter applied to JSP pages
does not always return gzip response header
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716132#action_12716132 ]
Malcolm Edgar commented on CLK-557:
-----------------------------------
No objections to Spring Security, better to be on this version.
I think we should probably document this issue in the PerformanceFilter Javadoc
> PerformanceFilter applied to JSP pages does not always return gzip response header
> ----------------------------------------------------------------------------------
>
> Key: CLK-557
> URL: https://issues.apache.org/jira/browse/CLK-557
> Project: Click
> Issue Type: Bug
> Reporter: Bob Schellink
> Assignee: Bob Schellink
> Priority: Blocker
>
> When including JSP pages it seems there are conditions under which the gzip header is not returned to the browser. Thus the raw bytes are displayed.
> More strange is that the issue arise only when the size of the Page exceeds a certain threshold. This threshold does not seem to be related to the PerformanceFilter Gzip threshold of 384 bytes though.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CLK-557) PerformanceFilter applied to JSP pages
does not always return gzip response header
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bob Schellink resolved CLK-557.
-------------------------------
Resolution: Fixed
Fix Version/s: 2.1.0
Fix checked in. This also fixes a problem reported by Florin where PerformanceFilter can throw exceptions if the underlying response stream is closed more than once.
> PerformanceFilter applied to JSP pages does not always return gzip response header
> ----------------------------------------------------------------------------------
>
> Key: CLK-557
> URL: https://issues.apache.org/jira/browse/CLK-557
> Project: Click
> Issue Type: Bug
> Reporter: Bob Schellink
> Assignee: Bob Schellink
> Priority: Blocker
> Fix For: 2.1.0
>
>
> When including JSP pages it seems there are conditions under which the gzip header is not returned to the browser. Thus the raw bytes are displayed.
> More strange is that the issue arise only when the size of the Page exceeds a certain threshold. This threshold does not seem to be related to the PerformanceFilter Gzip threshold of 384 bytes though.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CLK-557) PerformanceFilter applied to JSP pages
does not always return gzip response header
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716660#action_12716660 ]
Bob Schellink commented on CLK-557:
-----------------------------------
Turns out that Spring Security (Acegi) does not interfere with setting headers but it could be a catalyst.
According to the JSP spec section 5.4, when a JSP fragment is included through <jsp:include>, no headers can be set on the HttpServletResponse which is associated with that fragment. From what I can tell Spring Security triggers a flush to the underlying Writer while the fragment is being parsed. This in turn forces the GZIPOutputStream to be created and the Content-Encoding header to be set. But because this occurs within the fragment, no header is set and compressed bytes are displayed by the browser as is.
To fix it we can change the border-template.js include statement from:
<jsp:include page='${forward}'/>
to
<jsp:include page='${forward}' flush="true"/>
The extra flush statement forces a flush "before" the include occurs while the HttpServletResponse header can still be set.
I'm also making some changes to CompressionStream that if a header cannot be set, no compression should occur. Thus if users forget to flush before the include, the Page will still render correctly, albeit without being compressed.
Lastly we should probably set the "Vary" header tag as well. See here for details: http://wiki.squid-cache.org/KnowledgeBase/VaryNotCaching
> PerformanceFilter applied to JSP pages does not always return gzip response header
> ----------------------------------------------------------------------------------
>
> Key: CLK-557
> URL: https://issues.apache.org/jira/browse/CLK-557
> Project: Click
> Issue Type: Bug
> Reporter: Bob Schellink
> Assignee: Bob Schellink
> Priority: Blocker
>
> When including JSP pages it seems there are conditions under which the gzip header is not returned to the browser. Thus the raw bytes are displayed.
> More strange is that the issue arise only when the size of the Page exceeds a certain threshold. This threshold does not seem to be related to the PerformanceFilter Gzip threshold of 384 bytes though.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CLK-557) PerformanceFilter applied to
JSP pages does not always return gzip response header
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715963#action_12715963 ]
Bob Schellink edited comment on CLK-557 at 6/3/09 8:57 AM:
-----------------------------------------------------------
I have converted to Spring Security locally (not checked in yet), however the problem persists. Scanning through the Spring Security source code provides no clue as to what might be happening.
For example I've added the following snippet to CompressionResponseStream:
public void writeToGZip(byte b[], int off, int len) throws IOException {
if (gzipstream == null) {
response.addHeader("Content-Encoding", "gzip");
System.out.println("Contains encoding? " + response.containsHeader("Content-Encoding"));
This code simply prints whether the response contains the header that was added in the previous line.
For JSP pages that extends BorderPage the value is false.
I cannot find a trace in Spring Security where they override or swallow this method. Unless they use a Proxy to intercept method invocation.
Regarding Spring Security vs Acegi, it is mostly the same except for the configuration which, to me, looks much simpler.
Any objections on switching to Spring Security?
was (Author: sabob):
I have converted to Spring Security locally (not checked in yet), however the problem persists. Scanning through the Spring Security source code provides no clue as to what might be happening.
For example I've added the following snippet to CompressionResponseStream:
public void writeToGZip(byte b[], int off, int len) throws IOException {
if (gzipstream == null) {
response.addHeader("Content-Encoding", "gzip");
System.out.println("Contains encoding? " + response.containsHeader("Content-Encoding"));
This code simply prints whether the response contains the header that was added in the previous line.
For JSP pages that extends BorderPage the value is false.
I cannot find a trace in Spring Security where they override or swallow this method. Unless they use a Proxy to intercept the request.
Regarding Spring Security vs Acegi, it is mostly the same except for the configuration which, to me, looks much simpler.
Any objections on switching to Spring Security?
> PerformanceFilter applied to JSP pages does not always return gzip response header
> ----------------------------------------------------------------------------------
>
> Key: CLK-557
> URL: https://issues.apache.org/jira/browse/CLK-557
> Project: Click
> Issue Type: Bug
> Reporter: Bob Schellink
> Assignee: Bob Schellink
> Priority: Blocker
>
> When including JSP pages it seems there are conditions under which the gzip header is not returned to the browser. Thus the raw bytes are displayed.
> More strange is that the issue arise only when the size of the Page exceeds a certain threshold. This threshold does not seem to be related to the PerformanceFilter Gzip threshold of 384 bytes though.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CLK-557) PerformanceFilter applied to JSP pages
does not always return gzip response header
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715963#action_12715963 ]
Bob Schellink commented on CLK-557:
-----------------------------------
I have converted to Spring Security locally (not checked in yet), however the problem persists. Scanning through the Spring Security source code provides no clue as to what might be happening.
For example I've added the following snippet to CompressionResponseStream:
public void writeToGZip(byte b[], int off, int len) throws IOException {
if (gzipstream == null) {
response.addHeader("Content-Encoding", "gzip");
System.out.println("Contains encoding? " + response.containsHeader("Content-Encoding"));
This code simply prints whether the response contains the header that was added in the previous line.
For JSP pages that extends BorderPage the value is false.
I cannot find a trace in Spring Security where they override or swallow this method. Unless they use a Proxy to intercept the request.
Regarding Spring Security vs Acegi, it is mostly the same except for the configuration which, to me, looks much simpler.
Any objections on switching to Spring Security?
> PerformanceFilter applied to JSP pages does not always return gzip response header
> ----------------------------------------------------------------------------------
>
> Key: CLK-557
> URL: https://issues.apache.org/jira/browse/CLK-557
> Project: Click
> Issue Type: Bug
> Reporter: Bob Schellink
> Assignee: Bob Schellink
> Priority: Blocker
>
> When including JSP pages it seems there are conditions under which the gzip header is not returned to the browser. Thus the raw bytes are displayed.
> More strange is that the issue arise only when the size of the Page exceeds a certain threshold. This threshold does not seem to be related to the PerformanceFilter Gzip threshold of 384 bytes though.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CLK-557) PerformanceFilter applied to JSP pages
does not always return gzip response header
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715598#action_12715598 ]
Bob Schellink commented on CLK-557:
-----------------------------------
Turns out to be Acegi related. If I comment the filter out things go back to normal. Will try and figure out what Acegi is doing because it seems to remove the Content-Encoding header.
We should probably use Spring security instead as that seems to be the recommended library?
> PerformanceFilter applied to JSP pages does not always return gzip response header
> ----------------------------------------------------------------------------------
>
> Key: CLK-557
> URL: https://issues.apache.org/jira/browse/CLK-557
> Project: Click
> Issue Type: Bug
> Reporter: Bob Schellink
> Assignee: Bob Schellink
> Priority: Blocker
>
> When including JSP pages it seems there are conditions under which the gzip header is not returned to the browser. Thus the raw bytes are displayed.
> More strange is that the issue arise only when the size of the Page exceeds a certain threshold. This threshold does not seem to be related to the PerformanceFilter Gzip threshold of 384 bytes though.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CLK-557) PerformanceFilter applied to JSP pages
does not always return gzip response header
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715922#action_12715922 ]
Malcolm Edgar commented on CLK-557:
-----------------------------------
Reviewing the changes in Spring Security
http://jira.springframework.org/browse/SEC?report=com.atlassian.jira.plugin.system.project:changelog-panel
There appears to be no content encoding related fixes
> PerformanceFilter applied to JSP pages does not always return gzip response header
> ----------------------------------------------------------------------------------
>
> Key: CLK-557
> URL: https://issues.apache.org/jira/browse/CLK-557
> Project: Click
> Issue Type: Bug
> Reporter: Bob Schellink
> Assignee: Bob Schellink
> Priority: Blocker
>
> When including JSP pages it seems there are conditions under which the gzip header is not returned to the browser. Thus the raw bytes are displayed.
> More strange is that the issue arise only when the size of the Page exceeds a certain threshold. This threshold does not seem to be related to the PerformanceFilter Gzip threshold of 384 bytes though.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.