Re: gzip/squid patch

Mark Swanson wrote:

>On November 16, 2002 10:45 am, Mark Swanson wrote:
>  
>
>>If Miles hasn't already created a patch, here's what I have done:
>>
>>#define HEADER_PART3V "\r\nVary: Content-Encoding"
>>
I hadn't yet.   Mmmm...sleep...

>Heh. How did "Content-Encoding" slide in? It was "Accept-Encoding" in the 
>previous gzip/caching URL. Content-Encoding makes sense as the server may or 
>may not return (or vary) "Content-Encoding: gzip". I'm using 
>"Content-Encoding" in development and production and it works.
>
>The mod_gzip module for Apache uses "Accept-Encoding" (Sept 2002)
>
And I think that mod_gzip is correct.

  http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12.1

The server is not telling the proxy what response headers may vary; 
 It's telling the proxy what client request headers may vary: what the 
client could send that would make the response vary.

>http://lists.over.net/pipermail/mod_gzip/2002-September/006474.html.
>
>As I have cleared my squid and IE caches and everthing works great with 
>"Content-Encoding" - and this makes sense to me - I would recommend this 
>value be used.
>
>Would anyone have any reason why mod_gzip would work differently?
>Any reason why using "Content-Encoding" is not correct?
>
I don't think it is correct.  Everything I have read so far from the 
HTTP RFCs seems to indicate that "Vary" specifies varying client 
headers, not varying server headers.  I think you got lucky with your 
results.  A client never sends "Content-Encoding" and so this "Vary" 
header should have no effect.  Perhaps it is an unknown value to Squid 
and they don't cache if there is an unknown?

FYI: A "Vary" header with a value of "*" tells the proxy that it cannot 
cache the resource at all.  Not really important to this discussion, but 
someone may find the info useful since we are talking about "Vary" headers.

Joe Cooper wrote:

> Squid 2.5.STABLE1 does support Vary headers, and obeys them...so if 
> you send a vary header, older Squids won't cache it, new Squids will 
> cache it correctly.  (I think.  Henrik wrote the code, and Robert 
> spent some time on the mod_gzip/Squid-Dev lists hashing out what 
> happens when.  I can't seem to get any search results from the 
> squid-dev list right now, so I don't have a link to point to---but it 
> is definitely in the archives.)

If this is the case, I think that it would make sense to only specify 
"Vary: Accept-Encoding" when the compression proc variable is non-zero. 
 After all, if the variable is zero, the content encoding never varies, 
right?  I think that is correct behavior.  If you want the header to 
always be sent, you could always turn compression on but never generate 
a *.gz on the filesystem.  This would more accurately represent the 
possibility of varying content without ever actually supplying it.

Patch forthcoming and I'll try to find some web space for it so people 
can have a URL.

Anything I missed or misunderstood?

- Miles