W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2007

Re: etag vs if-* vs range vs content-encoding?

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Fri, 02 Feb 2007 11:42:08 +0100
To: PA <petite.abeille@gmail.com>
Cc: ietf-http-wg@w3.org
Message-Id: <1170412928.24864.27.camel@henriknordstrom.net>
tor 2007-02-01 klockan 21:59 +0100 skrev PA:

> I'm a bit confused on how the different HTTP entity transformations 
> work together... or not. In other words, from an HTTP server 
> perspective, how does one properly combine things like entity tags, 
> conditional requests, ranges and content encoding to name a few?

content-encoding is a property of the entity. If you recode the object
it needs to get assigned a new ETag, and also a new Content-Location (or
none). Content-Encoding is a result of server-driven content negotiation
just as Content-Language etc and is best thought of as a server having
both file and file.gz and selecting which of the two objects to send
based on accept-encoding.

conditionals and range selection should logically be processed when you
have finished processing the request and know what would be the response
without the conditionals. Conditionals never cause a server to return
different content, only short-circuit the response if any of the
conditionals is false. 

A false if-range conditional means you should ignore the Range request
header and process the request just as if the Range request header was
not there.

206 partial content responses is special. These are fragments of the
underlying 200 response send if there was no Range request header.
Entity headers is the same as the 200 response, except for the headers
used to indicate the ranges contained in the response.

There is some disagreement on what Content-MD5 means in a 206 response,
and to keep sanity Content-MD5 is best ignored.

ETag and any other entity headers (if any) sent in a conditional or
range response must be identical to that of a response to the same
request without any conditionals.


Received on Friday, 2 February 2007 10:42:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:41 UTC