Re: Content-Length and 304

On Sat, Sep 22, 2012 at 9:09 AM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

> That looks good to me:
>
> The length of the body section MUST be specified whenever there is a body.
> This MAY be indicated using Content-Length or Chunked ecoding [or MAY be
> some other negotiated encoding]
>
> Content-Length MAY be specified for a 304 response (and possibly a list of
> others) and MUST be the length of the content referenced if specified.
>
> I am a little worried though about this business of whether there is a
> body or not. That seems confusing and possibly means that the client has to
> understand the error code to know whether to look for the body or not.
>

While I agree it can be confusing, I just wanted to note that clients
already have to understand the HTTP status code, as per section RFC 2616
section 4.3:
"""

For response messages, whether or not a message-body is included with
   a message is dependent on both the request method and the response
   status code (section 6.1.1). All responses to the HEAD request method
   MUST NOT include a message-body, even though the presence of entity-
   header fields might lead one to believe they do. All 1xx
   (informational), 204 (no content), and 304 (not modified) responses
   MUST NOT include a message-body. All other responses do include a
   message-body, although it MAY be of zero length.

"""

and
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-3.3.3
"""

   1.  Any response to a HEAD request and any response with a 1xx
       (Informational), 204 (No Content), or 304 (Not Modified) status
       code is always terminated by the first empty line after the
       header fields, regardless of the header fields present in the
       message, and thus cannot contain a message body.

"""


>
>
> I suggest that we grandfather the existing response codes and specify any
> exceptions (304 being one, are there others) and for the rest have the rule
> that if Content-Length (or a content-encoding) is specified then there MUST
> be a body and it indicates the length of the body. If there is no body the
> content length MUST be omitted.
>
> Would it harm things to make this a universal rule?
>
>
> On Sat, Sep 22, 2012 at 1:11 AM, Roy T. Fielding <fielding@gbiv.com>wrote:
>
>> On Sep 19, 2012, at 6:22 PM, Zhong Yu wrote:
>>
>> > In the latest bis draft, a 304 response SHOULD set Content-Length
>> > equal to the length of the would-be payload body.
>> >
>> > ====
>> >
>> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-3.3.2
>> > 3.3.2. Content-Length
>> >
>> > ... a Content-Length header field SHOULD be sent to indicate the
>> > length of the payload body that ... would have been present had the
>> > request been an unconditional GET.
>> >
>> > ...In the case of a 304 response to a GET request, Content-Length
>> > indicates the size of the payload body that would have been sent in a
>> > 200 response.
>> > ====
>> >
>> >
>> > However, RFC2616 was not specific on the matter. If a server
>> > implementation always sets "Content-Length: 0" for 304 responses, it
>> > was acceptable.
>>
>> No, that has never been acceptable --- a change in content-length
>> will cause a cache flush on many deployed implementations
>> (Netscape introduced that in the mid 90s), and will truncate
>> valid responses in others.
>>
>> Depending on how you read 2616, the SHOULD send Content-Length
>> did not apply to messages that are not allowed to have a body.
>> Hence, it was considered valid to not send Content-Length on 304.
>> I messed that up when I merged the several paragraphs into
>> one requirement.
>>
>> I have attempted a fix in
>>
>>   http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1908
>>
>> that should remove any ambiguity about when content-length is
>> sent.  Please review.
>>
>> ....Roy
>>
>>
>>
>
>
> --
> Website: http://hallambaker.com/
>
>