In the days that I was forced to write my own HTTP server implementation, I totally avoided Locale functions, to avoid this particular type of problems. It's safer to create a few string arrays with the proper (english) values and use those for day/month names. Actually, I think the HTTP spec is silly - it should have used YYYY-MM-DDTHH:MM:SS like RFC3339, not this weird format intended for us meek humans.
> -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: donderdag 17 december 2009 22:18 > To: Tomcat Users List > Subject: Re: AW: Re: AW: RE: RE: Ignore http header if-modified-since > > -----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 > > > This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
