tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: AW: Re: AW: RE: RE: Ignore http header if-modified-since
Date Thu, 17 Dec 2009 21:17:42 GMT
Hash: SHA1


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.

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
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())

        // Ignore any call from an included servlet
        if (included) {

        if (format == null) {
            format = new

        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
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message