Re: Content-Length and 304

How about HTTP/1.0 clients, as far as you know - if the connection is
keep-alive, can they handle 204/304 framing correctly if
Content-Length is missing, or set to a non-zero value. What's the best
effort to keep a 1.0 connection alive when responding 204/304? Or is
it safer to just close the connection after responding.

On Thu, Sep 20, 2012 at 12:11 AM, Willy Tarreau <w@1wt.eu> wrote:
> Hi,
>
> On Wed, Sep 19, 2012 at 08:22:27PM -0500, 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. But now it becomes non-compliant under the new spec.
>>
>> Is this new requirement really necessary? Who would benefit from it?
>
> I remind an old application I saw about 10 years ago which fell into
> this trap of sending "Content-Length: 0" along with 304 responses. The
> result was blank pages for clients fetching these responses from a cache
> (apache 1.3), because the cache used the headers fetched from the response
> to update the ones it had in the cache and subsequently delivered empty
> objects only.
>
> I think that *all* header fields must be sent with a 304 as they would
> have been with the real response, it avoids such trouble.
>
>> 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
>
> It's true that this part is confusing, we all have an exception for this
> in client code to ignore the length (suggestion #2 above).
>
> However, we also know that at least some clients break if we send a wrong
> content length, so it should probably be the same if we don't send any.
> In my opinion, better leave this untouched to remain compatible with what
> is deployed. If you think that some points are still confusing in the spec,
> maybe we should try to improve the wording to remove any confusion.
>
> Regards,
> Willy
>

Received on Thursday, 20 September 2012 05:44:25 UTC