Re: Content-Length and 304

On Wed, Sep 19, 2012 at 10:11 PM, Willy Tarreau <w@1wt.eu> wrote:
> 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.

This defeats a common optimization in Web frameworks where a request
comes in with an ETag, and you have a trick where you compute the ETag
based on last-update timestamps of a couple of tables and maybe a
global update sequence number, and if the ETag matches you fire off
the 304 and go to sleep, having saved lots of IO & templating.

So the right thing to do is to either send headers which match the
real response, or don’t send them. -T


>
>> 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 06:05:55 UTC