On May 7, 2008, at 7:01 PM, Roy T. Fielding wrote:
On May 7, 2008, at 9:25 AM, Dirk-Willem van Gulik wrote:
But to me allowing caching modules some knowledge of HTTP is
probably good - as
optimizing the generic case is simply not worthwhile - the very
point of caches
is that they understand something of the biz-processes to go beyond
what a the
operating system and what not can yield.
Please keep in mind that Vary is an instruction from the origin
server to
external caches that it does not control. A cache within an origin
server
or reverse proxy/gateway is free to ignore Vary if so configured.
Thus, an
internal cache may have two sets of instructions -- one "internal
vary"
that guides its operation and another Vary header field that is
intended
for external recipients of a message.
Which is why I intentionally stopped short of hiding this completely
in the cache_utils - but instead let the caching modules 'choose' if
they follow up, change, have their own and/or use (or totally ignore)
vary.
Or am I misreading you - and are you suggesting that we should have an
extra layer in there - i.e. bury the vary aspect for the storage part
of the cache - and have a separate layer for the 'is this equal' logic
(rather than having them bundled in one, as it is now) ?
Dw
