Bugzilla – Full Text Bug Listing
| Summary: | Date Resolution on HttpFields.putDateField() is lacking | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] Jetty | Reporter: | Nobody <nobody104074> | ||||
| Component: | server | Assignee: | Greg Wilkins <gregw> | ||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | jetty-inbox | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 7.2.x | ||||||
| Hardware: | Macintosh | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 193210 [details]
roundup patch
This patch will round up all date handling to the second.
I have prepared a patch, but I'm not going to apply it for now. I am concerned that such a change will break existing code that is written against the current round down logic. I'll ponder the impacts a bit more before applying. Sorry but I'm not going to change this behaviour - which has been as it is for many years and hundreds of thousands of websites. While I agree that in hind site, better rounding would have been appropriate, I think it is too late now to change. The code needed to round down yourself is simple. Actually, this is a good argument of E-Tags, as they could use the ms timestamp to give better resolution. |
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.