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=6709>.
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=6709

Images on protected areas have not "Last modified" header





------- Additional Comments From [EMAIL PROTECTED]  2002-04-25 17:21 -------
This default no-cache on secured resources has significant effects on the .ram 
files used by RealPlayer. These files must be cached when the browser passes 
control to RealPlayer, which then uses the cached file. I assume this kind of 
hand-off is similar with other (all?) external programs called by the browser. 
Netscape and Opera ignore the no-cache headers for the .ram files, but IE does 
not and RealPlayer cannot find the .ram file via IE.

To work around this, I had to create a servlet filter mapped to *.ram that sets 
the Cache-Control to private via response.setHeader("Cache-Control","private"). 
This one setting proved sufficient for the .ram file info to "pass" to 
RealPlayer via the cached file.

Preventing caching and protecting web resources in the container should work 
together, but I question the assumption that the no-cache headers should be a 
mandatory part of the container's security responsibility. In other words, this 
assumes the container's job necessarily includes trying to manage how clients 
(and proxies) treat its resources once outside the container.

I would like to see this no-cache feature be optional. It is an important thing 
to be able to set, but there needs to be more control over its exact settings, 
and to what resources the settings should be applied. 

It could be great if this were fully configurable in Tomcat and the no-cache 
resource mappings could be described in the server.xml (or web.xml if it were 
added to the web app spec). Otherwise, servlet filters are a good way to 
implement this.

Thanks
J F

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to