Last-Modified HTTP header from mod_dav_svn

[Erik Huelsmann]

I want to discuss one possible feature for mod_dav_svn.
The idea is very basic: let mod_dav_svn set the
"Last-Modified" HTTP header to last modification time
of requested resource in repository (only files, I'm not sure
what to do with directories).
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.
What respected community think about this?

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
isn't cacheable.

However, right as we speak, a thread is going on in the dev@ mailing
list (I forwarded this mail there) about the usefulness of being able
to cache HTTP trafic between a client and the repository server.

Maybe you can step

[Kalle Olavi Niemitalo]

Post by Erik Huelsmann

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
isn't cacheable.

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.

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]

Post by Kalle Olavi Niemitalo

Post by Erik Huelsmann

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
isn't cacheable.

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
conditional get...)

Post by Kalle Olavi Niemitalo
I suppose there could be two advantages with reporting Last-Modified
- 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.