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

RE: How to make mod_svn_dav return a last-modified header?

From: Julian Reschke <julian.reschke_at_gmx.de>
Date: 2003-08-07 18:22:59 CEST

I really don't understand what this has to do with cache-friendliness... An
HTTP/1.1 should be absolute enthusiastic about the presence of the ETag, and
not use Last-Modified at all in this case.

What am I missing?

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> -----Original Message-----
> From: Chris Croome [mailto:chris@webarchitects.co.uk]
> Sent: Thursday, August 07, 2003 6:17 PM
> To: kfogel@collab.net
> Cc: users@subversion.tigris.org
> Subject: Re: How to make mod_svn_dav return a last-modified header?
>
>
> Hi
>
> On Wed 06-Aug-2003 at 10:42:06 +0100, Chris Croome wrote:
> >
> > On Wed 06-Aug-2003 at 10:25:01AM -0500, kfogel@collab.net wrote:
> > > I think we did this in revision 6636, resolving issue #971.
> > >
> > > Can you check the change against those docs and let us know if we
> > > missed anything important?  That would be a big help, thanks...
> >
> > OK, I need to upgrade from version 0.24.1 (r6278) first though!
>
> Right I'm now running a new version:
>
>  [root@atomism i386]# rpm -qa subversion
>  subversion-0.26.0-6658
>
> And there are still no Last-Modified headers being produced (The ETag
> looks OK though):
>
>   [chris@snowball chris]$ lynx -head -dump
> http://atomism.demon.co.uk/svn/repos/morris/morris.jpg
>   HTTP/1.1 200 OK
>   Date: Thu, 07 Aug 2003 16:11:19 GMT
>   Server: Apache/2.0.47 (Red Hat Linux)
>   ETag: "1//morris.jpg"
>   Accept-Ranges: bytes
>   Connection: close
>   Content-Type: application/octet-stream
>
> And as a result it's not very cache friendly:
>
>
> http://www.ircache.net/cgi-bin/cacheability.py?query=http://atomis
> m.demon.co.uk/svn/repos/morris/morris.jpg
>
>   Expires             -
>   Cache-Control       -
>   Last-Modified       -
>   ETag                "1//morris.jpg"
>   Content-Length      8.8K (9059)
>   Server              Apache/2.0.47 (Red Hat Linux)
>
>   This object will be considered stale, because it doesn't have any
>   freshness information assigned. The object had changed when validation
>   was attempted.
>
> The best thing would be if an Last-Modified header was produced that
> matched the date when the file was last changed:
>
>   Validators are very important; if one isn't present, and there isn't
>   any freshness information (Expires or Cache-Control) available, most
>   caches will not store an object at all.
>
>   The most common validator is the time that the document last changed,
>   the Last-Modified time. When a cache has an object stored that
>   includes a Last-Modified header, it can use it to ask the server if
>   the object has changed since the last time it was seen, with an
>   If-Modified-Since request.
>
>   Almost all caches use Last-Modified times in determining if an object
>   is fresh; as more HTTP/1.1 caches come online, Etag headers will also
>   be used.
>
>   http://www.mnot.net/cache_docs/#VALIDATE
>
> Chris
>
> > > Chris Croome <chris@webarchitects.co.uk> writes:
> > > >
> > > >   Caching Tutorial for Web Authors and Webmasters
> > > >   http://www.mnot.net/cache_docs/
> > > >
> > > >   Cacheability Engine
> > > >   http://www.mnot.net/cacheability/
>
> --
> Chris Croome                               <chris@webarchitects.co.uk>
> web design                             http://www.webarchitects.co.uk/
> web content management                               http://mkdoc.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 7 18:24:02 2003

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

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