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

Re: Content-Length and 304

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 20 Sep 2012 08:17:53 +0200
To: Tim Bray <tbray@textuality.com>
Cc: Zhong Yu <zhong.j.yu@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20120920061753.GH413@1wt.eu>
On Wed, Sep 19, 2012 at 11:05:27PM -0700, Tim Bray wrote:
> 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

Well, I don't know what the cache did when the header was not sent, but
I would not be surprized that it would consider the object as empty.
Don't get me wrong, I'm not saying this is fine nor a desired behaviour,
I'm talking about issues I've had to deal with in production.

What we're documenting in this spec is how to ensure the best
interoperability. If people have 100% positive experience with not
returning a content-length when the request contains an if-none-match,
maybe that's acceptable too, but I have not made the tests.

Received on Thursday, 20 September 2012 06:19:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC