Re: DATE-IF-MODIFIED

Ross Patterson:
>
>jg@pa.dec.com (Jim Gettys) writes:

>>                                                               rather than
>>(perhaps) playing games based on the official semantics of If-Modified-Since."
>
>Let's stop after "... in the Last-Modified date" and delete the remainder
>of the sentence.  That way we wind up with a normative statement, rather
>than one that calls into question the motivation of the change or limits
>the interpretation of its scope.

I fully agree with deleting language like `playing games'.  In
particular because the proposed language implies that some clients
playing games were the source of the thouble, while it actually was
servers playing games with the official rfc1945 semantics in order to
limit the impact of some bugs in a deployed client.

>To summarize the above, here's my suggested replacement:
>
>   "Note: An HTTP client should expect that If-Modified-Since headers
>   sent for cache validation will be interpreted by the origin server
>   and all intervening proxy servers as requesting an exact match
>   between the supplied HTTP-date and the last modification date and
>   time of the resource.  In other words, an HTTP client should preserve
>   all of the accuracy in the Last-Modified HTTP-date."

I like the above replacement better, but I still find that it puts
some blame where it does not belong.  Here is my replacement:

   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, clients should use the exact date string recieved in
   a previous Last-Modified header field whenever possible.

>Ross Patterson

Koen.

Received on Tuesday, 9 September 1997 11:50:56 UTC