On Wed, Sep 26, 2012 at 7:27 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 09/26/2012 12:28 PM, Philip Martin wrote:
>> Branko Čibej <brane_at_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
Received on 2012-09-26 19:43:58 CEST