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

Re: Content-Length and 304

From: Roy T. Fielding <fielding@gbiv.com>
Date: Sat, 22 Sep 2012 00:07:12 -0700
Cc: Zhong Yu <zhong.j.yu@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <C05B1535-7407-4FEE-BF14-6039096A1144@gbiv.com>
To: Tim Bray <tbray@textuality.com>
On Sep 21, 2012, at 10:59 PM, Tim Bray wrote:

> Roy, thatís a hairy diff, I was having trouble with it,

It is easier if you skip the html part and just look at the
diff on the xml source.  Next time I will remember to include the
fragment ...

 http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1908#file1

> but I think itís saying that you MAY send a CL with a 304 containing the correct size, which is what we want.  Given the record of bad practice in this space, might it be worth while to say the server MUST NOT act stupid and send a 0 or anything else inaccurate? -T

Given the unbounded set of stupid things a server might do,
I'd rather not.  However, I can restrict it further.

Instead of 

   A server &MAY; send a Content-Length header field in a 
   <x:ref>304 (Not Modified)</x:ref> response to a conditional GET request 
   (&status-304;) in order to indicate the size of the payload body, 
   excluding any potential transfer-coding, that would have been sent in a 
   <x:ref>200 (OK)</x:ref> response. 

how about

   A server &MAY; send a Content-Length header field in a 
   <x:ref>304 (Not Modified)</x:ref> response to a conditional GET request 
   (&status-304;); a server &MUST-NOT; send Content-Length in such a response
   unless its field-value equals the decimal number of octets that would
   have been sent in the payload body of a <x:ref>200 (OK)</x:ref> response
   to the same request.

Cheers,

....Roy
Received on Saturday, 22 September 2012 07:07:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 22 September 2012 07:07:48 GMT