Kalle Olavi Niemitalo wrote:
> Erik Huelsmann <email@example.com> writes:
>>On 9/15/05, Sergey Proskurnya <firstname.lastname@example.org> wrote:
>>>This will allow to use Internet Caching (Squid)
>>>very effectively, which will result in lower traffic and
>>>performance improvement for remote users, who are using
>>>casual HTTP browser to access to SVN repository.
>>It's a great idea, but won't work. Currently Subversion requests
>>REPORTs from the server. These are unique for every single session
>>between a client and a server. Thus, the REPORT response we're using
> However, if a "casual HTTP browser" contacts a Subversion repository,
> it will be using GET, which could be cacheable.
> On the other hand, mod_dav_svn is already generating ETag headers,
> and an HTTP/1.1 cache can put the entity tag in an If-None-Match
> request header, and presumably get back a 304 Not Modified status,
> in the same way it would with Last-Modified and If-Modified-Since.
Note that according to the RFC, a strict interpretation would require
both the ETag and teh Last-Modified header in order to allow the client
side to use a conditional get. I found this out the hard way (did not
read the RFC closely enough) and had to update the Insurrection RSS and Atom
feeds to fill in both ETag and the Last-Modified header. (I was only
doing ETag since that is what I thought was the minimum set needed for
> I suppose there could be two advantages with reporting Last-Modified
> in addition to ETag:
> - Perhaps some older caches support Last-Modified but not ETag.
> - A cache can guess an expiry date based on how long the resource
> has already been unmodified.
> - RFC 2616 section 13.3.4 says servers SHOULD do so.
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:email@example.com
My place on the web http://www.sinz.org/Michael.Sinz
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Nov 25 22:10:49 2005