EDITs to 10.3.5 (304 Not Modified)

These edits reflect my understanding and recollection of the consenus
developed during today's editorial teleconference.  Anyone who wishes
hould do so immediately, since the deadline for the next I-D submission
is less than 24 hours from now.

The intention of these changes is to clarify what headers are sent
with 304 (Not Modified) responses.  This subject resulted in a
lengthy discussion during the teleconference, and although I believe
that the resulting words are correct, they merit careful scrutiny.

10.3.5 304 Not Modified

Replace

    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 response MUST NOT contain a message-
    body. Header fields contained in the response MUST include any values
    that, if an unconditional request had been made, might be different from
    values sent with any prior response for the entity The response MUST
    also include any values that caches use for matching requests and
    responses with cache entries. The response SHOULD NOT include header
    fields whose values cannot possibly have changed, such as Content-Type.
    Examples of relevant header fields include: Date, Server, Content-
    Length, Content-MD5, Content-Version, Cache-Control, ETag, Vary and
    Expires.

with

    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 response MUST NOT contain a message-
    body.
    
    The response MUST include the following header fields:
	.   Date
	.   ETag and/or Content-Location, if the header would have been
		sent in a 200 response to the same request
	.   Expires, Cache-Control, and/or Vary, if the field-value
		might differ from that sent in any previous response
		for the same variant
    If the conditional GET used a strong cache validator (see section
    13.3.3), the response SHOULD NOT include other entity-headers.
    Otherwise (i.e., the conditional GET used a weak validator),
    the response MUST NOT include other entity-headers; this prevents
    inconsistencies between cached entity-bodies and updated headers.

Our belief is that these rules for including headers in 304 responses
solves the following problems:
	(1) it provides those headers necessary for matching responses
	with cache entries
	
	(2) it provides those headers that might be necessary for
	updating cachability information for a previous response
	
	(3) it prevents inconsistencies that otherwise could arise with
	the use of weak validators if the cached entity body is not
	consistent with the current state of the variant (such as
	a semantically insignificant change in length)

	(4) it discourages, but does not prevent, the use of other
	headers.

-Jeff

Received on Thursday, 6 June 1996 15:08:43 UTC