0

We are using the "Last-Modified" response header from the server and the "If-Modified-Since" request header for the resource validation. HTTP header definitions states that the "If-Modified-Since" SHOULD contain value received from the server (it does not prohibit usage of another value). At some point we started using a "last updated time" as value for the "If-Modified-Since" sent from the client. The "last updated time" is the time when client last time received an update from server (either new version of the resource or 304 error). We were told that we must not use any client generated time because of possible time synchronization issues.

Of course all times are expressed in GMT.

I could not find confirmation that this is a requirement. It would be nice to hear espert's opinion on it is a MUST to use a value returned from server as a value for the "If-Modified-Since" or there is some degree of flexibility? In what circumstances it is possible to use client generated time?

Thanks a lot

LeonidVlad
  • 83
  • 8

2 Answers2

1

If the client's clock is ahead of the server's clock, it is invalid to specify a date/time that is after the server's current clock (the HTTP spec even says so).

If the client's clock is behind the server clock's, at the very least you might end up with a 200 reply when you might be expecting a 304 reply instead, which is not an error but would waste bandwidth sending a really-unmodified resource.

Either way, you are better off using the server's date/time values. In fact, the HTTP spec does says so in section 14.25:

Note: When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than function, for deciding whether to send a 304 (Not Modified) response. To get best results when sending an If- Modified-Since header field for cache validation, clients are advised to use the exact date string received in a previous Last- Modified header field whenever possible.

Note: If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for the same request, the client should be aware of the fact that this date is interpreted in the server's understanding of time. The client should consider unsynchronized clocks and rounding problems due to the different encodings of time between the client and server. This includes the possibility of race conditions if the document has changed between the time it was first requested and the If-Modified-Since date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified- Since date is derived from the client's clock without correction to the server's clock. Corrections for different time bases between client and server are at best approximate due to network latency.

Community
  • 1
  • 1
Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • Thank you, good answer. So, client should better use server-side generated time but (if it is aware of problems) it *may* violate the rule. – LeonidVlad Apr 29 '13 at 22:48
0

If the client's clock is ahead of the server's clock, the client could miss ever getting an update if it asks for documents modified since it last received a copy using its own clock. Suppose the client clock is 5 seconds ahead. Consider this sequence of events:

  • At 1:00:00 by the server clock, 1:00:05 according to the client clock, Document X is created.
  • At 2:30:00 by the server clock, 2:30:05 according to the client clock, client asks to get Document X.
  • Server sends Document X with a Last-Modified header of 1:00:00.
  • At 2:30:03 by the server clock, Document X is modified.
  • At around 3:30, Client asks for Document X if it has been modified since 2:30:05.
  • Server replies, Not Modified.

It's not that the client has specified a time in the future from the server's point of view. The problem is that it won't get the document that was modified an hour before, because it's telling the server it already has it.

Bob Kanefsky
  • 121
  • 1
  • 9