Okay, I narrowed this down a bit more with some help from Alex Rousskov:
When it works (doing a string replace from "asdf" to "fdsa" for example, so
same total content length):
2011/01/26 16:07:21.312| storeEntryValidLength: Checking
'1078B4E8EC1D17CFEBCD533EE19F7FD6'
2011/01/26 16:07:21.312| s
On Mon, 24 Jan 2011 20:57:08 +0100, Henrik Nordström wrote:
> mån 2011-01-24 klockan 17:46 +1300 skrev Amos Jeffries:
>
>> AFAIK, that proper variant handling was not yet ported to squid-3. Only
>> in squid-2 right now.
>
> Correct, but even the basic variant handling is 1->N. The difference is
mån 2011-01-24 klockan 17:46 +1300 skrev Amos Jeffries:
> AFAIK, that proper variant handling was not yet ported to squid-3. Only
> in squid-2 right now.
Correct, but even the basic variant handling is 1->N. The difference is
that the basic mode do not merge equal responses, and each possible
re
On 24/01/11 13:43, Henrik Nordström wrote:
lör 2011-01-22 klockan 23:04 +1300 skrev Amos Jeffries:
Squid caches only one of N variants so the expected behviour is that
each new variant is a MISS but becomes a HIT on repeated duplicate
requests until a new variant pushes it out of cache.
No it
In my test, yes, the web server was responding with Vary:
Accept-Encoding. But that's only because of the behavior below, where
once a non-gzipped version is cached (i.e. a request comes in first
with no Accept-Encoding header at all) all subsequent requests get the
unzipped version, even if prese
sön 2011-01-23 klockan 14:14 -0800 skrev Jonathan Wolfe:
> I'm using the values of "asdf" for a bogus Accept-Encoding value that
> shouldn't trigger gzipping, and "gzip" for when I actually want to
> invoke the module. To be clear, the webserver isn't zipping at all.
Is the web server responding
lör 2011-01-22 klockan 23:04 +1300 skrev Amos Jeffries:
> Squid caches only one of N variants so the expected behviour is that
> each new variant is a MISS but becomes a HIT on repeated duplicate
> requests until a new variant pushes it out of cache.
No it caches all N variants seen if the orig
> Vary in Squid is currently treated as an exact-match text key. So when asked
> for a "gzip,deflate" variant Squid does not have enough smarts to serve the
> "deflate" variant. So it MISSes and gets a fresh one, which may or may not
> be gzipped, but is served gzipped to the client anyway.
Right
On 22/01/11 19:22, Jonathan Wolfe wrote:
First, request and reply headers for a cached version, as gzip isn't included
in the Accept-Encoding header.
Request:
GET /styles/media.css HTTP/1.1
User-Agent: httperf/0.9.0
Host: www.example.com
Accept-Encoding: deflate
Reply:
HTTP/1.0 200 OK
Cache-
First, request and reply headers for a cached version, as gzip isn't included
in the Accept-Encoding header.
Request:
GET /styles/media.css HTTP/1.1
User-Agent: httperf/0.9.0
Host: www.example.com
Accept-Encoding: deflate
Reply:
HTTP/1.0 200 OK
Cache-Control: max-age=86400
Expires: Sun, 23 Jan
On 22/01/11 11:43, Jonathan Wolfe wrote:
With squid (3.1.8 - .10) in reverse-proxy mode running an eCAP
adapter (gzip), does squid still pull the body to be gzipped from its
cache? I'm setting Vary: Accept-Encoding, and seeing HITs when
Accept-Encoding doesn't include gzip, but only MISSes when
With squid (3.1.8 - .10) in reverse-proxy mode running an eCAP adapter (gzip),
does squid still pull the body to be gzipped from its cache? I'm setting Vary:
Accept-Encoding, and seeing HITs when Accept-Encoding doesn't include gzip, but
only MISSes when the adapter is gzipping. Is this by des
12 matches
Mail list logo
