httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrik Nordstrom <...@squid-cache.org>
Subject Re: Wrong etag sent with mod_deflate
Date Sat, 09 Dec 2006 21:01:59 GMT
fre 2006-12-08 klockan 15:35 -0800 skrev Justin Erenkrantz:

> As Kevin mentioned, Squid is only using the ETag and is ignoring the
> Vary header.  That's the crux of the broken behavior on their part.
> If they want to point out minor RFC violations in Apache, then we can
> play that game as well.  (mod_cache deals with this Vary/ETag case
> just fine, FWIW.)

We are not at all ignoring Vary, but we are using If-None-Match to ask
the server which one of the N already cached entities belonging to the
resource URI is valid for this specific request, indirectly learning the
server side content negotiation logics used.

> The compromise I'd be willing to accept is to have mod_deflate support
> the 'TE: gzip' request header and add 'gzip' to the Transfer-Encoding
> bit - and to prefer that over any Accept-Encoding bits that are sent.

Would be a great move if you can not make it behave correct in the
content space.

But if you make mod_deflate behave according to the RFC then sending
Content-Encoding: gzip is fine to me. But TE is a much better fit from
the RFC point of view.

> The ETag can clearly remain the same in that case - even as a strong
> ETag.

Yes.

> So, Squid can change to send along TE: gzip (if it isn't
> already).

TE: gzip is likely to appear in 3.1.

> And, everyone else who sends Accept-Encoding gets the
> result in a way that doesn't pooch their cache if they try to do a
> later conditional request.

As long as mod_deflate continues ignoring the RFC wrt ETag there will
conflicts with various cache implementations.

> Is that acceptable?  -- justin

Intentionally not following a MUST level requirements in the RFC is not
an acceptable solution in my eyes. For one thing even if you ignore
everyone else it would make it impossible for Apache + mod_deflate to
claim RFC 2616 HTTP/1.1 compliance.

Regards
Henrik

Mime
View raw message