Mailing-List: contact click-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: click-dev@incubator.apache.org
Message-ID: <44198060.1244044688077.JavaMail.jira@brutus>
Date: Wed, 3 Jun 2009 08:58:08 -0700 (PDT)
From: "Bob Schellink (JIRA)" <jira@apache.org>
To: click-dev@incubator.apache.org
Subject: [jira] Issue Comment Edited: (CLK-557) PerformanceFilter applied to
 JSP pages does not always return gzip response header
In-Reply-To: <138479520.1243957507356.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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