Re: Content-Length and 304

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.

Regards,
Willy

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