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. Perhaps the server should send the X-SVN-VR-Base header back? I suppose the server admin might be able to use mod_headers to send Cache-Control: no-cache if a dodgy cache is known to be affecting clients, although a dodgy cache might ignore that. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
