Re: Content-Length and 304

Aw crud I had forgotten the connection close thing

304 post dated CL but predated keep alive.

Main thing is not making any more exceptions.

Sent from my iPhone

On Sep 22, 2012, at 2:15 PM, "Roy T. Fielding" <fielding@gbiv.com> wrote:

On Sep 22, 2012, at 10:23 AM, Phillip Hallam-Baker 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.


See the quoted text. "All other responses do include a message body,
although it may be of zero length."

What you suggested (don't send Content-Length) means the body size
is unknown and the client continues reading until the connection is
closed.  That's the only way it could have been defined given that
HTTP/1.0 existed before C-L was defined for framing.  It seems
to work well enough.

....Roy

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/