Description Nobody 2011-04-13 09:29:08 EDT

Build Identifier: 7.3.1.v20110307

If I wish to set the HTTP Response Header "Last-Modified" with the value - 

response.setDateHeader("Last-Modified", 1302623933241)

then Jetty sends this to the browser as the value - Tue, 12 Apr 2011 15:58:53 GMT

This is incorrect as the millisecond component has been disregarded, we have in effect lost 241 milliseconds.

Which means when the browser sends me back the value to Jetty in the next request for the same resource as the "If-Modified-Since" Request Header then Jetty gives me this - 1302623933000.
I then again lookup the last modified date of the resource requested and get 1302623933241 when I compare this against the value request.getDateHeader("If-Modified-Since") (302623933000) then it always appears to me that the resource has been modified and so I cannot return HTTP 304 Not-Modified.

Now I could of course round-up the millisecond component of the timestamp to the nearest second before passing it to Jetty as the Last-Modified header, but somehow it seems to me that Jetty should be responsible for ensuring the round-trip of Date fields in the HTTP Headers. The issue seems to be in Jettys HttpFields.putDateField() in particular the _formatDate(...) function.

I am not sure how other Servlet Containers handle this, and I cannot find that the Servlet spec defines how this long should be mapped to the HTTP Header equivalent.

Reproducible: Always

Steps to Reproduce:
Try round-tripping a date with milliseconds resolution via the HTTP Response Header Last-Modified and then processing the resulting HTTP Request Header If-Modified-Since.