[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: General question on Serf

From: Bert Huijben <bert_at_vmoo.com>
Date: Wed, 26 Sep 2012 09:53:19 -0700

To what url was this request?

I don't think it is to the public URL, or is it?

This might be part of the answer.

Bert Huijben (Cell phone)
From: Philip Martin
Sent: 26-9-2012 18:29
To: Branko Čibej
Cc: dev_at_subversion.apache.org
Subject: Re: General question on Serf
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.

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
Received on 2012-09-26 18:53:52 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.