Hola,
Hello. I am using Tomcat 4.1.30, with java 1.4.2 on a Readhat linux server. I was going to submit a bug report, but I noticed the bug tracker only goes through version 4.1.9. Is that bug tracker still being used? Should I still submit bugs to it?
Look again ;) The bug tracker goes through 4.1.30, it's just a string sort so 4.1.30 is in the middle and 4.1.9 is at the end.
doh!
I looked at the onjava cache before starting, and it didn't work quite like I want. I want something that works essentially like an HTTP cache proxy. So it caches based on the headers of the outgoing response. The second link simply adds headers to your response. My preference, for setting cache headers, is to set them inside the servlet, since only it should know whether a response can/should be cached. At any rate, it's not a super complicated filter and I'm just about finished with it anyway.
Anyway, I am implementing an HTTP Cache filter using the Java Servlet
You can save yourself some effort and use an existing free filter such as those in http://www.onjava.com/pub/a/onjava/2004/03/03/filters.html or http://www.servletsuite.com/servlets/responseflt.htm (there are many others, you can just google).
When I look at the actual HTTP generated response I'm finding that my attempt to set the "Date" header is being ignored and the date of the header always reflects the time "now". So when my filter returns a
Are you sure you're not setting it to "now" ? ;)
Yeah, I'm pretty sure. ;)
Actually, I only set it if I'm not calling doChain: the filter has decided the cached response is fresh so it sends that rather than working up the chain.I can see only one place in the tomcat code that sets this header: the Coyote Http11Processor (org.apache.coyote.http11.Http11Processor in the jakarta-tomcat-connectors CVS module). That code does a check to make sure it's not overwriting an existing header with the same name. Furthermore, even if this code sets the header, you second call would overwrite the currently set value. You're setting it in your filter after the doChain call, right?
As an experiment I used setHeader( "Date", dateString ) intead of setDateHeader( "Date", timestamp ). The setHeader() call is actually respected, so the problem seems to be only with the setDateHeader() method. I guess the headers set via setHeader() and via setDateHeader() must live in seperate data structures and only the one is getting checked. For obvious reasons it's preferable to just use the setDateHeader() method but I can always use a SimpleDateFormat object to do the string conversion myself.
(Actually, my above paragraph is looking at the 5.0.27 source code, but I think 4.1.30 is the same in this area).
Uh oh. You're going to make me download the 4.1.30 source aren't you. ;)
thanks for your help, rossi
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
