Re: Returning HTTP/1.0 206 responses

On Thu, Apr 26, 2012 at 9:50 AM, Henrik Nordström
<henrik_at_henriknordstrom.net> wrote:
>
> tor 2012-04-26 klockan 18:39 +0200 skrev Henrik Nordström:
> > ons 2012-04-25 klockan 18:12 -0700 skrev Andrew Scherkus:
> >
> > > I tested out the http11 option on squid/2.7 and caching worked as
> > > expected in both Chromium and Firefox. I suppose my questions are:
> > >   1) Should squid really be returning HTTP/1.0 on 206 responses when
> > > 206 was defined as part of HTTP/1.1?
> >
> > Imho yes. And Apache also agrees on this.
> >
> > Why do you think it's not? What problem do you see from HTTP/1.0 206
> > responses?
>
> A related note is that at least Apache agrees with us, and happily
> answers with HTTP/1.0 206 when seeing an HTTP/1.0 Range request.
>
> I also have not heard of any interop issues before your mail, and Squid
> have been doing this since 1996.

Thanks for the explanation!

As far as Chromium is concerned we use ETag headers as a strong
validator to determine when we should cache content and when to
invalidate and re-fetch content should the ETag change. Since ETag and
ranges aren't technically part of the HTTP/1.0 spec we ignore them and
skip caching the content.

In other words, we maintain a high bar for deciding when to cache
content but will always attempt to render the content even if it
doesn't meet our caching requirements. The consequences of caching the
wrong thing results in rendering errors that can persist between
reboots, versus a transient error that can get fixed by simply
reloading the page.

I guess there's not much to do here until more folks update to
squid-3.1.2 or later :)

Andrew
Received on Fri Apr 27 2012 - 20:52:09 MDT