httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Wrong etag sent with mod_deflate
Date Sat, 09 Dec 2006 20:38:39 GMT
> And please stop lying about Squid.

C'mon Henrik. No one is intentionally trying to LIE about Squid.

If you are referring to Justin quoting ME let me supply a big
fat MEA CULPA here and say right now that I haven't looked
at the SQUID Vary/ETag code since the last major release
and I DO NOT KNOW FOR SURE what SQUID is doing ( or
not doing ) if/when it sees the same (strong) ETag for both
a "compressed" and an "identity" version of the same entity.


I should have made that perfectly clear along with any
opinion previously offered.

I apologize for that.

I also DID already state clearly in another post...

> I don't know the exact details of the exact "field problem"
> that Henrik is trying to solve...

Keyphrase --"don't know the exact details"

In my other posts, I was suggesting, however, that even if
an upstream content server ( Apache ) is not sending separate
unique ETags I am still having a hard time understanding why
that would cause SQUID to deliver the wrong "Varied" response
back to the user.

Something is nagging at me telling me that EVEN IF the same
(strong) ETag happens to be on both a compressed and a
non-compressed version of the SAME ENTITY that there 
shouldn't be a big "problem in the field" ( sic: A user not
getting what they asked for ). 

A compressed version of an entity IS the same entity... for
all intents and purposes... it just has "compression" 
applied. One cannot possibly become "stale" without the
other also being "stale" at the same exact moment in time.

> If you think something in our cache implementation of
> Vary/ETag is not right then say what and back it up with RFC reference.

At the moment... yes... I do... but if you read my other posts I
also have a feeling the reason I can't quote you Verse and Chapter
from an RFC is because I have a sneaking suspicion that there
is something "missing" from the ETag/Vary scheme that can 
lead to problems like this... and it's NOT IN ANY RFC YET.

It has something to do with being "too literal" about a spec and
ignoring "common sense".

In other words... you may be doing exactly what hours and hours
of reading an RFC seems to be telling you you SHOULD do... but
there still might be something "else" that OUGHT to be done.

I hope the discussion continues.

This is something that has been "lurking" for years now and it
needs to get resolved.

There will always be the chance that some upstream server will
( mistakenly? ) keep the same (strong) ETag on a compressed
variant. People are not perfect and they make mistakes. I still
think that even when that happens any caching software should
follow the "be lenient in what you accpet and strict in what you
send" rule and still use the other information available to it
( sic: What the client really asked for and expects ) and 
"do the right thing". Only the cache knows what the client
is REALLY asking for.


View raw message