tomcat-dev mailing list archives

DO NOT REPLY [Bug 6709] - Images on protected areas have not "Last modified" header

Date

Thu, 25 Apr 2002 17:21:16 GMT

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 jfienberg@simmedia.com 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:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>