Re: caching proxies and SVN network perf

On Tue, Oct 24, 2000 at 10:33:09AM -0500, Jim Blandy wrote:
>
> If there were some way to encode in the URL the request for the delta
> from version N to M, then caching the reply in the dumbest way might
> actually work.

HTTP caches can use the URL and the contents of multiple headers to do the
caching (i.e. multiple-valued key into the cache). That is considered
"better form" than encoding stuff into the URL. There are also more
effective ways to do caching if the URL is not encoded with add'l
information.

Consider if we make a request like this (based on the design in the HTTP
delta encoding Internet Draft(*)):

  GET http://host/repos/$svn/ver/10.100.5
  If-None-Match: "10.100.1"
  A-IM: svndiff, gzip

[ 10.100.5 is the file/version we are requesting; "10.100.1" is the
  entity-tag for the version we have; A-IM states what delta encodings we
  understand ]

In the above request, the server has enough information to generate the diff
for us. However, the above request *also* works against a non-diff-capable
server -- the If-None-Match and A-IM headers would be ignored and the whole
file would simply be returned.

This "fallback" is an important part in being able to talk to different
DeltaV repositories. Some can do diffs, other can't. But in all cases, the
client will get enough information to continue.

One point that I need to look at some more is the use of If-None-Match to
indicate the version the client has. That is a standard header, but it
doesn't make sense in this context: we're requesting 10.100.5 and we *know*
that it won't have an entity tag of 10.100.1. I'll dig in a bit more into
the draft to see if there is a pattern that works better for our design and
DeltaV in general.

Cheers,
-g

(*) http://www.ietf.org/internet-drafts/draft-mogul-http-delta-07.txt

-- 
Greg Stein, http://www.lyra.org/