Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4B2A9FF6.5060503@christopherschultz.net>
Date: Thu, 17 Dec 2009 16:17:42 -0500
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
 rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: AW: Re: AW: RE: RE: Ignore http header if-modified-since
References: <H00000db0054c7d4.1261069687.postamt.berlin.dilax.com@MHS>
In-Reply-To: <H00000db0054c7d4.1261069687.postamt.berlin.dilax.com@MHS>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org