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

Re: Content-Length and 304

From: Tim Bray <tbray@textuality.com>
Date: Wed, 19 Sep 2012 23:05:27 -0700
Message-ID: <CAHBU6iu7daKMu=43cw2ijOBJEMCqQfYXt7bYofPw+zqEFwqMJQ@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Zhong Yu <zhong.j.yu@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:06 UTC