click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Schellink (JIRA)" <>
Subject [jira] Commented: (CLK-557) PerformanceFilter applied to JSP pages does not always return gzip response header
Date Fri, 05 Jun 2009 16:24:07 GMT


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}'/>
  <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:

> PerformanceFilter applied to JSP pages does not always return gzip response header
> ----------------------------------------------------------------------------------
>                 Key: CLK-557
>                 URL:
>             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.

View raw message