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: Wed, 19 Sep 2012 22:01:30 -0500
Message-ID: <CACuKZqEgkqfNgU-hV=Hrt78Dt9+BBu-vaszf21xLqk=w-vyVgg@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: Tim Bray <tbray@textuality.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Sep 19, 2012 at 9:35 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> I see no benefit either. I am certain that there is no benefit if
> implementation is less than 100% and I am pretty sure there isn't a point if
> there is 100% implementation.
>
> It also boxes the use of the conditional get in. Say the conditional get is
> for a generated page with lots of content that is user specific and an
> article that is updated from time to time. The server would have to do a lot
> of work to calculate the content length for the generated page but it can
> check to see if it needs to refresh by checking the sources.

I guess the author intended the header to be optional - only set it if
convenient.

Nevertheless, previously Content-Length was meaningless in 204/304
responses; now it is assigned a meaning in 304. That can be
surprising.

Zhong Yu

>
> If we are going to make any change here I would suggest the opposite
> approach and deprecate sending a Content-Length other than 0.
>
> I would like to see those two purposes separate in HTTP/2.0 in any case.
>
>
>
> On Wed, Sep 19, 2012 at 10:22 PM, Tim Bray <tbray@textuality.com> wrote:
>>
>> I had missed this. I just revisited 2616 and unless I misread, this is
>> a new thing.  This appears to me to add substantial workload to the
>> server and I donít comprehend the benefit.  Either I missed something,
>> or YAGNI.  -T
>>
>> On Wed, Sep 19, 2012 at 6:22 PM, Zhong Yu <zhong.j.yu@gmail.com> 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. But now it becomes non-compliant under the new spec.
>> >
>> > Is this new requirement really necessary? Who would benefit from it?
>> >
>> > According to the reasoning of
>> >
>> > ====
>> >
>> > http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-20#section-4.1
>> > 4.1. 304 Not Modified
>> > Since the goal of a 304 response is to minimize information transfer
>> > when the recipient already has one or more cached representations, the
>> > response SHOULD NOT include representation metadata other than the
>> > above listed fields
>> > ====
>> >
>> > we SHOULD NOT include Content-Length in 304 responses either.
>> >
>> > I think the meaning of Content-Length is confusing enough, in the case
>> > of 204/304 response, it's better to require that
>> > 1. server SHOULD NOT set Content-Length
>> > 2. client MUST ignore Content-Length
>> >
>> > Zhong Yu
>> >
>>
>
>
>
> --
> Website: http://hallambaker.com/
>
Received on Thursday, 20 September 2012 03:01:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 September 2012 03:02:04 GMT