You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by getridofthespam <ge...@yahoo.com> on 2013/03/11 16:17:05 UTC

date format in Last-modified header

Hi,

Google didn't give any relevant info so I try here.

I traced a tomcat request and noticed there where two different date formats in the 
last-modified header:
2012-12-13T09:52:02Z
and
Mon, 07 Jan 2013 21:49:08 GMT

What determines the format and where do the differences come from?

tnx in advance for all replies

Re: date format in Last-modified header

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

André,

On 3/11/13 5:31 PM, André Warnier wrote:
> Just by coincidence, I happened to be looking at some HTTP/DAV
> output right now (from Apache's DAV), and I noticed this : ... 
> <D:getcontenttype>application/pdf</D:getcontenttype> 
> <lp1:creationdate>2012-12-21T09:25:53Z</lp1:creationdate> 
> <lp1:getlastmodified>Fri, 21 Dec 2012 09:25:53
> GMT</lp1:getlastmodified> 
> <lp1:getcontentlength>1009325</lp1:getcontentlength> 
> <lp1:resourcetype/> ...

What is the XML Schema being used for the document? I suspect that
whatever the "lp1" namespace resolves to indicates that the timestamp
should be in xs:dateTime format which /does/ have that format. I dunno
if XML Schema allows you to constrain PCDATA, though...

Anyhow, consumers of XML will *expect* that all timestamps are in this
format. IMHO, it's a much better format than what HTTP specifies for
date headers, as it's (nearly) all numeric. Too bad Java's
SimpleDateFormat can neither emit nor consume dates in that format.
Fortunately, Apache commons has a drop-in replacement for
SimpleDateFormat that *does* support it.

> So there we have these 2 formats within a same HTTP response from
> the same module on the same server and about the same file, both of
> which could obviously have used the same format.

You're thinking about it in the wrong way(s).

First, HTTP only makes claims about the response headers: once the
headers are done, it's all bits after that... HTTP has no prevue there.

Second, standards are standards. Just because the HTTP date standard
is stupid doesn't mean you can just change it to something "better".
That would be ... non-standard. What we would need is a new HTTP
header field (e.g. Last-Modified-Not-Stupid) that is defined to be in,
say, ISO 8601 date format, or even xs:dateTime format or whatever. The
problem is that most HTTP-aware toolkits treat date header values all
the same -- take a look at HttpServletRequest.getDateHeader()... it
will parse a date header using the HTTP standard. We'd have to add a
HttpServletRequest.getNonStupidDateHeader() method, etc.

Unfortunately, HTTP is pretty much stuck forever.

XML has its own rules: xs:dateTime. It's appropriate to use them
because the document being returned is XML.

> Why make it simple when complicated will do ?

Complaining that the commonly-used XML date format doesn't agree with
the HTTP date format is like complaining that Microsoft Excel doesn't
store dates in ISO 8601 date format but instead as Julian dates in a
binary document format.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlE/TNwACgkQ9CaO5/Lv0PBaigCgi77IYLBmeDp+HW3FirF65H2I
C+8AoIIx7I9C6XlWRSn1AHL1s4Sq062j
=Y4y6
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: date format in Last-modified header

Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> To whom it may concern,
> 
> On 3/11/13 11:17 AM, getridofthespam wrote:
>> Google didn't give any relevant info so I try here.
>>
>> I traced a tomcat request and noticed there where two different
>> date formats in the last-modified header: 2012-12-13T09:52:02Z and 
>> Mon, 07 Jan 2013 21:49:08 GMT
>>
>> What determines the format and where do the differences come from?
> 
> RFC 2616 (HTTP)[1] does not directly reference RFC 2822 (Internet
> Message Format), but that's the format that's being used -- covered in
> section 3.3 [2]. That's where the format that begins with the day-of-week.
> 
> I'm surprised that Tomcat ever emits anything that looks like
> yyyyMMddTHHmmssZZ -- that's ISO 8601 date formats. Since ISO 8601
> predates HTTP, I'm not sure why that wasn't chosen. But HTTP has some
> old crap that should have never been put into the protocol from day
> one, so why not an insane date format specification?
> 

Just by coincidence, I happened to be looking at some HTTP/DAV output right now (from 
Apache's DAV), and I noticed this :
...
<D:getcontenttype>application/pdf</D:getcontenttype>
<lp1:creationdate>2012-12-21T09:25:53Z</lp1:creationdate>
<lp1:getlastmodified>Fri, 21 Dec 2012 09:25:53 GMT</lp1:getlastmodified>
<lp1:getcontentlength>1009325</lp1:getcontentlength>
<lp1:resourcetype/>
...

So there we have these 2 formats within a same HTTP response from the same module on the 
same server and about the same file, both of which could obviously have used the same format.
Why make it simple when complicated will do ?




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: date format in Last-modified header

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

To whom it may concern,

On 3/11/13 11:17 AM, getridofthespam wrote:
> Google didn't give any relevant info so I try here.
> 
> I traced a tomcat request and noticed there where two different
> date formats in the last-modified header: 2012-12-13T09:52:02Z and 
> Mon, 07 Jan 2013 21:49:08 GMT
> 
> What determines the format and where do the differences come from?

RFC 2616 (HTTP)[1] does not directly reference RFC 2822 (Internet
Message Format), but that's the format that's being used -- covered in
section 3.3 [2]. That's where the format that begins with the day-of-week.

I'm surprised that Tomcat ever emits anything that looks like
yyyyMMddTHHmmssZZ -- that's ISO 8601 date formats. Since ISO 8601
predates HTTP, I'm not sure why that wasn't chosen. But HTTP has some
old crap that should have never been put into the protocol from day
one, so why not an insane date format specification?

- -chris

[1] http://tools.ietf.org/html/rfc2616#section-13.3.1
[2] http://tools.ietf.org/html/rfc2822#section-3.3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlE+Qm4ACgkQ9CaO5/Lv0PBWZgCgtPmB6J8EVB6nZgOv57EmEvvX
ScsAniX9s6fDJNmHFAbbfDuDClo7T1X5
=VS3F
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: date format in Last-modified header

Posted by André Warnier <aw...@ice-sa.com>.
getridofthespam wrote:
> Hi,
> 
> Google didn't give any relevant info so I try here.
> 
> I traced a tomcat request and noticed there where two different date formats in the 
> last-modified header:
> 2012-12-13T09:52:02Z
> and
> Mon, 07 Jan 2013 21:49:08 GMT
> 
> What determines the format and where do the differences come from?
> 

According to Perl's help, these formats orginate from :
They correspond to the C library routines strftime and ctime.

Searching Google for that, this page provides a lot more information :
http://linux.die.net/man/3/strftime

I am also sure that there must be an RFC (2616?) that mentions the various acceptable 
formats in HTTP. Mmmm. For example, searching Google for "http rfc date format" yields 
this : https://tools.ietf.org/html/rfc3339) (and also a reference to RFC 2616).

Now, how from there they make their way into Tomcat's "last-modified" headers, I wouldn't 
know.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org