Issue: BYTE-RANGE (Is the right meta-data returned on range requests?)

Summary of discussion:

There is no need for a new return code - it can all be handled using 206.
When responding to an If-Range validation request, the server should only
send the strictly required subset of headers.

Suggested Solution:

1) Section 10.2.7 should look like this:

The server has fulfilled the partial GET request for the resource. The
request must have included a Range header field (section 14.36) indicating
the desired range, and may have included an "If-Range" header field
(section 14.27) to make the request conditional.

The response MUST include the following header fields:

     o	Either a Content-Range header field (section 14.17) indicating the
	range included with this response, or a multipart/byteranges
	Content-Type including Content-Range fields for each part. If
	multipart/byteranges is not used, the Content-Length header field
	in the response MUST match the actual number of OCTETs transmitted
	in the message-body.

     o	Date

     o	ETag and/or Content-Location, if the header would have been sent in
	a 200 response to the same request
 
     o	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 206 response is the result of an If-Range request that used a strong
cache validator (see section 13.3.3), the response SHOULD NOT include other
entity-headers. If the response is the result of an If-Range request that
used a weak validator, the response MUST NOT include other entity-headers;
this prevents inconsistencies between cached entity-bodies and updated
headers. Otherwise, the response MUST include all of the entity-headers
that would have been returned with a 200 (OK) response to the same request.

A cache MUST NOT combine a 206 response with other previously cached
content if the ETag or Last-Modified headers do not match exactly, see 13.5.4

A cache that does not support the Range and Content-Range headers MUST NOT
cache 206 (Partial) responses.

2) In section "14.27 If-Range", last paragraph, the two "should"'s marked
with * should be uppercase as they are part of the specification:

If the entity tag given in the If-Range header matches the current entity
tag for the entity, then the server *should* provide the specified
sub-range of the entity using a 206 (Partial content) response. If the
entity tag does not match, then the server *should* return the entire
entity using a 200 (OK) response.

3) Section "13.5.3 Combining Headers" should look like this:

When a cache makes a validating request to a server, and the server
provides a 304 (Not Modified) response or a 206 (Partial Content) response,
the cache must construct a response to send to the requesting client.

In the status code is 304 (Not Modified), the cache uses the entity-body
stored in the cache entry as the entity-body of this outgoing response. If
the status code is 206 (Partial Content) and the ETag or Last-Modified
headers match exactly, see 13.5.4, the cache may combine the contents
stored in the cache entry with the new contents received in the response
and use the result as the entity-body of this outgoing response, see 13.5.4.

The end-to-end headers stored in the cache entry are used for the
constructed response, except that any end-to-end headers provided in the
304 or 206 response MUST replace the corresponding headers from the cache
entry. Unless the cache decides to remove the cache entry, it MUST also
replace the end-to-end headers stored with the cache entry with
corresponding headers received in the incoming response.

In other words, the set of end-to-end headers received in the incoming
response overrides all corresponding end-to-end headers stored with the
cache entry. The cache may add Warning headers (see section 14.45) to this
set.

If a header field-name in the incoming response matches more than one
header in the cache entry, all such old headers are replaced.

Note: this rule allows an origin server to use a 304 (Not Modified) or a
206 (Partial Content) response to update any header associated with a
previous response for the same entity or sub-ranges thereof, although it
might not always be meaningful or correct to do so. This rule does not
allow an origin server to use a 304 (Not Modified) or a 206 (Partial
Content) response to entirely delete a header that it had provided with a
previous response.

Comments?

Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Monday, 12 May 1997 08:03:16 UTC