click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Schellink (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CLK-557) PerformanceFilter applied to JSP pages does not always return gzip response header
Date Wed, 03 Jun 2009 15:58:08 GMT

    [ 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.


Mime
View raw message