> 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. Period. I DO NOT KNOW FER SURE. 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. Yours... Kevin
