DO NOT REPLY [Bug 6732] New: - No way to enable browser caching for resource protected by

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6732>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6732

No way to enable browser caching for resource protected by <security-contstraint>

           Summary: No way to enable browser caching for resource protected
                    by <security-contstraint>
           Product: Tomcat 4
           Version: 4.0.2 Final
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Blocker
          Priority: Other
         Component: HTTP/1.1 Connector
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: jemiller@uchicago.edu


In Tomcat 4.0.2 release a change was made in AuthenticatorBase.java on lines  
484-486 so that it includes the following lines.

sresponse.setHeader("Pragma", "No-cache");
sresponse.setHeader("Cache-Control", "no-cache");
sresponse.setDateHeader("Expires", 1);

This has the affect of turning caching off for applications that use a 
<security-constraint>. For example, if they were protected by SSL.

I understand that this change was made so that caching/proxy servers would 
know not to cache these pages.

However, IMHO, one should be able to set "Cache-Control" to "private" to 
acheive the same thing but still allow caching on the client. i.e. I think 
there should be a way for the developer to override the default behavior.

The problem is that the Servlet API provides no means for removing headers 
that have already been set in the HttpServletResponse short of clearing all 
the headers which is something that you normally wouldn't want to do because 
there might be other important headers that shouldn't be cleared, for example, 
the jsessionid cookie. Note, you can set headers, but not remove them. Also, 
unlike for a HttpServletRequest object, you can't query and enumerate what 
headers have been set, in this case by the Web server itself.

One potential fix IMHO would be to make it so that if you call 
HttpServletResponse.setHeader() with a value of null that it remove the header.

Another possibility would be to make the behavior configurable via a 
configuration file (preferrable).

Also, why is the "expires" header being set? As far as I know, you 
setting "Pragma" (for backwards compatibility) and "Cache-Control" should be 
sufficient to disable caching.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>