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

Re: Content-Length and 304

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Sat, 22 Sep 2012 12:30:53 -0500
Message-ID: <CACuKZqG95kRxBz80ZKft=aTSmee4GVrWv_VijOdR6FQVQgHLhg@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
I guess any new response code would have to have a body. So the
body-less oddity is contained in present state forever.

On Sat, Sep 22, 2012 at 12:23 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> I would like to be able to add in new response codes if that looks like it
> is useful.
>
> That is not possible if sending an unknown response code causes an existing
> client to lose framing. All that a client needs to know at present is how to
> interpret the first digit of the code. Provided the unknown code is a 1xx,
> 2xx, 3xx, 4xx or 5xx as appropriate then the client should not break.
>
> The rules seem to be designed to allow this behavior but some people seem to
> have implemented them in ways that introduce ambiguity. What I am suggesting
> is that we tighten the guidance so that the ambiguity is eliminated. That
> does not cause any loss of backwards compatibility and it improves forward
> compatibility. I think that is a win-win.
>
>
>
>
> On Sat, Sep 22, 2012 at 12:27 PM, William Chan (ι™ˆζ™Ίζ˜Œ) <willchan@chromium.org>
> wrote:
>>
>> 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/
>>>
>>
>
>
>
> --
> Website: http://hallambaker.com/
>
Received on Saturday, 22 September 2012 17:31:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 22 September 2012 17:31:27 GMT