-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Abid,
On 12/17/2009 12:08 PM, Abid Hussain wrote: > I used the startup parameters > -Duser.language=en > -Duser.region=US > This caused Tomcat to deliver the Last-Modified in the correct format. > > That solved the problem, no 404 anymore, thanks. > > So it seems to be a bug in tomcat...? I would say so. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1 Tomcat's behavior seems to ignore the specification, here. Would you care to share your Tomcat version with us? Looking at the DefaultServlet, it looks like it ultimately uses org.apache.naming.resources.ResourceAttributes.getLastModifiedHttp(), which explicitly uses a US locale, though it doesn't specify en_US: /** * HTTP date format. */ protected static final SimpleDateFormat format = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss zzz", Locale.US); ... /** * @return Returns the lastModifiedHttp. */ public String getLastModifiedHttp() { if (lastModifiedHttp != null) return lastModifiedHttp; Date modifiedDate = getLastModifiedDate(); if (modifiedDate == null) { modifiedDate = getCreationDate(); } if (modifiedDate == null) { modifiedDate = new Date(); } synchronized (format) { lastModifiedHttp = format.format(modifiedDate); } return lastModifiedHttp; } Locale.US yields "en_US" on my system (LC_CTYPE=en_US.UTF-8). I tried messing with LC_TYPE and I see that: $ LC_CTYPE=en_US java LocaleTest Locale.default = en_US Locale.US = en_US $ LC_CTYPE=de_DE java LocaleTest Locale.default = de_DE Locale.US = en_US So, it looks like Locale.US always means en_US, though it wouldn't hurt to be explicit about the language, here. If Response.setDateHeader is called, you get this: public void setDateHeader(String name, long value) { if (isCommitted()) return; // Ignore any call from an included servlet if (included) { return; } if (format == null) { format = new SimpleDateFormat(DateTool.HTTP_RESPONSE_DATE_HEADER, Locale.US); format.setTimeZone(TimeZone.getTimeZone("GMT")); } setHeader(name, FastHttpDateFormat.formatDate(value, format)); } So, it looks like Tomcat 6.0.20 does things properly, at least when it comes to DefaultServlet and Response.setDateFormat. Oddly enough, these SimpleDateFormat objects are being created all the time even though the Response object is not guaranteed to be threadsafe... why not simply re-use the DateFormat object forever since it's always the same thing? Are you sure that this date header is coming from Tomcat's code? > Again my other question: How can I instruct tomcat not to put the > Last-Modified Header into the response at all? Do I have to use a filter > or can it be done by configuration? Or is is somehow not recommended > fiddle with the headers? It doesn't look like DefaultServlet has any options for this, so you'll have to do it with a filter or valve. If it's really Tomcat's code that is the problem, you almost certainly will need a Valve since the code might not be wrappable via a filter. I think it would be most interesting to see where that header is being set... I suspect this code hasn't changed for quite a while. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksqn/YACgkQ9CaO5/Lv0PBbeQCfYlW2uiVT4j0T1QMF+MLwVjLX EpkAmwf3lUMQZc6ikfVA64r8w9PD3jAk =vIOz -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
