Re: Last-Modified HTTP header from mod_dav_svn

Kalle Olavi Niemitalo <[email protected]> Fri, 25 Nov 2005 22:57:31 +0200
Newsgroups gmane.comp.version-control.subversion.devel,gmane.mail.eyebrowse.user
Message-ID <87hda0o37o.fsf__41085.3417976343$1132951961$gmane$org@Astalo.kon.iki.fi>
Erik Huelsmann <[email protected]> writes:

> On 9/15/05, Sergey Proskurnya <[email protected]> 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
> 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.
signature.asc (application/pgp-signature, 188 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBDh3rZHm9IGt60eMgRAuNfAKDGaXm63hvcYu+XqfloPddyiu5gUQCg0Lw5
z5gHv9eZpVfz2xft00xYTsQ=
=88S4
-----END PGP SIGNATURE-----