On 09/26/2012 12:28 PM, Philip Martin wrote: > Branko Čibej <br...@wandisco.com> writes: > >> This is how the cache /should/ work, according to any number of HTTP >> specs. Unfortunately, most proxies that I know about don't attempt >> anything as "advanced" as that. > > If the cache ignores X-SVN-VR-Base and simply caches the response that > will break 1.8 clients. Looking at the response: > > HTTP/1.1 200 OK > Date: Wed, 26 Sep 2012 16:20:33 GMT > Server: Apache/2.2.16 (Debian) mod_ssl/2.2.16 OpenSSL/0.9.8o DAV/2 > SVN/1.8.0-dev > Last-Modified: Wed, 26 Sep 2012 16:20:19 GMT > ETag: "2//f" > Cache-Control: max-age=604800 > Accept-Ranges: bytes > Transfer-Encoding: chunked > Content-Type: application/vnd.svn-svndiff > > I don't see a header that allows the client to confirm that that delta > is based on the requested revision. I suppose the client just assumes > that the server used the right base revision so if a cache returns the > wrong delta the client will get a checksum mismatch when constructing > the full-text.
That's right. The client only cares about that Content-Type header -- if "application/vnd.svn-svndiff", the content is expected to be a delta against the revision in the request's X-SVN-VR-Base header. > Perhaps the server should send the X-SVN-VR-Base header back? Wouldn't be a bad idea. At a minimum, a client could compare it with the one that was submitted in the GET request, and error out if they don't match. -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
