Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
Java-SCA-1.6
-
None
Description
The timestamp comparison performed by AtomBindingListenerServlet for the If-Modified-Since and If-Unmodified-Since HTTP headers can produce incorrect results in some cases.
Consider the following sequences of events.
Scenario A:
1. At time T1, a client of an Atom feed modifies the feed
2. The client then records the current time T2
3. The client then sends a GET request with If-Modified-Since: T2
4. The client expects the server to send a 304 response because the feed has not been modified since time T1. On some occasions this happens but on other occasions the server sends a 200 response.
Scenario B:
1. At time T1, a client of an Atom feed modifies the feed
2. The client then records the current time T2
3. The client then sends a GET request with If-Unmodified-Since: T2
4. The client expects the server to send a 200 response because the feed has not been modified since time T1. On some occasions this happens but on other occasions the server sends a 304 response.
These problems are caused by the millseconds component of time T2 being lost when time T2 is formatted as an exact number of seconds for insertion into the If-Modified-Since or If-Unmodified-Since header.
For example if the following applies:
T1 == 12:34:56.100
T2 == 12:34:56.300
the time T2 is transmitted by the client as 12:34:56.000 and appears to the server to be an earlier time than T1 (incorrect).
However if the following applies:
T1 == 12:34:56.900
T2 == 12:34:57.100
the time T2 is transmitted by the client as 12:34:57.000 and appears to the server to be a later time than T1 (correct).
This is the cause of the occasional test case failures described in TUSCANY-3299.
Attachments
Issue Links
- is part of
-
TUSCANY-3299 ATOM binding testcase failure ProviderFeedEntityTagsTestCase.testUnmodifiedGetIfUnModified
- Closed