On Wed, Sep 26, 2012 at 7:27 PM, C. Michael Pilato <cmpil...@collab.net> wrote: > 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. >
If the intention is to instruct the proxy that a cached response is only valid for a certain X-SVN-VR-Base header, then that is what the "Vary" header is for. So with: Vary: X-SVN-VR-Base in the response, the proxy should only return a cached response if the request for that cached response had the same value for X-SVN-VR-Base as the new request. Lieven
