[Http-crcsync] General comments on crcsync document

Patrick McManus mcmanus at ducksong.com
Thu Jul 9 17:31:53 EDT 2009


On Thu, 2009-07-09 at 23:07 +0200, Alex Wulms wrote:
> Op donderdag 9 juli 2009, schreef Patrick McManus:

> > I've seen caching proxies that basically say "whoa, too complicated" and
> > treat that as meaning "Cache-Control: no-cache", but they don't all do
> > that and it leaves room for good implementations. And in the case of
> > deltas it is not hard to imagine cache hits in such a scenario.

> Excellent. This will certainly simplify the protocol, assuming we can indeed 
> ignore issues about the rare but maybe still existing HTTP 1.0 proxies/caches 
> that don't know about the vary header.

right.

you should of course never respond to a 1.0 request while relying on a
1.1 feature for correctness (in this case "Vary"). But that starts to
get into general http-ness instead of deltas - which is in itself a good
reason not to specify it here. 

I would think you would just not do a delta in this case if you were the
server and recevied a 1.0 level request, but I suppose you might just
resort to all the usual cache-busting stuff instead. implementation
decision, in any case. and if you were a 1.1 proxy who received a delta
from the server side (because you made a 1.1 request to it) but were
servicing a 1.0 request from your own client then it would be incumbent
on you to plaster "Expires: 0" (or somesuch) on that response because of
the presence of the Vary you know the client isn't going to grok. You
don't need to know anything about the delta extension in order to know
what Vary (core rfc 2616) means. All of which is basically out of scope
for the crcsync spec (though interesting topics of implementation
discussion), imo.







More information about the Http-crcsync mailing list