Slava Bizyayev wrote:
> It's so good for me to meet you together in one so important for me
> discussion!
Agreed.
> As far as I remember our previous conversation with Henrik, Squid supports
> Vary correctly since stable version 2.0.
Correct, in the sense that all version Squid-2.0 to Squid-2.4 will
unconditionally block caching of objects using Vary due to limitations in
Squid cache management (Squid assumed one URL == one reply entity, which
isn't true for Vary objects). From 2.5 it will actually start to support
caching of Vary replies, with increased support in 2.6 (ETag).
> An interesting question I have to both of you is Who should care about
> known bugs in popular browsers? Should Squid take a part in this work?
Depends on what the bug affects. If the bug affects hop-by-hop features of
HTTP then Squid will need to take part. If the bug only affects end-to-end
features such as content-encoding (i.e. mod_gzip) then it is technically none
of Squid's business. HTTP is rather clear on the distinction between caching
proxies, user-agents and origin servers when it comes to reply entities,
their criterias and responsibilities, but it takes a while to crossread all
the sections to get the picture... (you first need to get the end-to-end vs
hop-by-hop picture, everything else related to caching/proxying depends on
this)
If mod_gzip starts to play with transfer-encoding then it will become Squids
business once Squid acheives HTTP/1.1, but then the playfield is set very
differently from the question on content-encoding. The two are fully separate
from each other. Any transfer-encoding bugs in browsers will then be Squids
problem, and mod_gzip would need to deal with transfer_encoding bugs in Squid
(if any).
Regards
Henrik
Received on Mon Aug 26 2002 - 15:25:22 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:16:14 MST