W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

sending Last-Modified in 304 and 206 responses

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 28 Jul 2010 02:06:59 -0700
Message-Id: <D83B1CFF-7F7E-462B-9FAB-8D464CF8A4CA@gbiv.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
While cleaning up the terminology for draft 11, I came across some
oddness in the definitions of 306 and 206.

First, the very simple requirement for what header fields to include
in the 304 response were spread over six paragraphs in an odd list
of MUST bullets with exceptions, including some exceptions that are
impossible to implement.  I replaced that with two paragraphs.
I did not do the same for 206, but it might be worth doing in
the future.

Second, I added Last-Modified to the list of header fields that MUST be
sent, if available for a given representation, for both 206 and 304,
because failing to update LM will impact the interoperability of later
conditional requests even if a strong validator is provided.

The current text for 304 now reads:
=========

3.1.  304 Not Modified

   If the client has performed a conditional GET request and access is
   allowed, but the document has not been modified, the server SHOULD
   respond with this status code.  The 304 response MUST NOT contain a
   message-body, and thus is always terminated by the first empty line
   after the header fields.

   A 304 response MUST include a Date header field (Section 9.3 of
   [Part1]) unless its omission is required by Section 9.3.1 of [Part1].
   If a 200 response to the same request would have included any of the
   header fields Cache-Control, Content-Location, ETag, Expires, Last-
   Modified, or Vary, then those same header fields MUST be sent in a
   304 response.

   Since the goal of a 304 response is to minimize information transfer
   when the recipient already has one or more cached representations,
   the response SHOULD NOT include representation metadata other than
   the above listed fields unless said metadata exists for the purpose
   of guiding cache updates (e.g., future HTTP extensions).

   If a 304 response includes an entity-tag that indicates a
   representation not currently cached, then the recipient MUST NOT use
   the 304 to update its own cache.  If that conditional request
   originated with an outbound client, such as a user agent with its own
   cache sending a conditional GET to a shared proxy, then the 304
   response MAY be forwarded to the outbound client.  Otherwise,
   disregard the response and repeat the request without the
   conditional.

   If a cache uses a received 304 response to update a cache entry, the
   cache MUST update the entry to reflect any new field values given in
   the response.

=========

I think it still needs some editing (along with the rest of p4),
but we wanted to note the changes in case there are any objections.

....Roy
Received on Wednesday, 28 July 2010 09:07:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:24 GMT