> On Sat 09-Aug-2003 at 04:23:06PM -0500, Ben Collins-Sussman wrote:
> > kfogel@collab.net writes:
> >
> > > His point, I think, is that if you do a checkout and get
> > > specific revisions of specific files, then there's no reason caches
> > > shouldn't be able to use this fact. Yet our checkout caused no
> > > caching at all -- what a waste.
>
> Yeah, it was originally raised by someone else I do think it would
> be good to fix it.
Hi there,
I raised the original point (and it seems to have opened a proverbial
worm can ;-) about last-modified headers.
I'll briefly explain the context of the problem I am running into..
I work for Amnesty International. We are using Subversion to hold the
xml/xslt source code for some internal websites. We have an xml/xslt
transformation server under Tomcat (similar to Cocoon) that accesses the
source xslt/xml directly out of Subversion and creates a dynamic website.
Not what you envisioned Subversion being used for? :-)
The live website is accessed from a versioned URL (eg.
http://svn.xyz.net/repos/xyz.net/!svn/bc/64/branches/r1/) but the
development versions are accessed from direct urls in trunk or branches (eg.
http://svn.xyz.net/repos/xyz.net/trunk/).
So there are two cases.
1) Can the production xslt being pulled from the versioned URL be cached?
Obviously this will have performance implications for the production sites.
Naturally there are workarounds involving copying the XSLT to flat files but
the native subversion solution is neater and simpler.
2) Development is done using XMLSpy and PUT requests straight into the
repository trunk (or branches). The development website has a transformation
engine pointing at the subversion trunk. The goal is to enable developers in
different locations to be able to contribute -- hence the use of DAV for
editing. Here it is more important to ensure that content is NOT cached or
that the cache isn't operating too aggressively.
> > Maybe I misunderstood the thread. I saw you guys looking at the
> > ethereal trace of 1) GET requests on public URLs, and 2) PROPFINDs,
> > and being surprised at not seeing 'Last-modified' headers anywhere.
> > And I was just saying, well, yes, this is to be expected.
>
> Do you think it would be good to have them?
As you can see we are using Subversion for things beyond its original scope!
The tool is so flexible and robust that these sort of edge use cases pretty
much work as expected. In this case though, the lack of last-modified
headers is a problem.
I don't understand the workings of Subversion with respect to diffed
resources and the x-svn header but it seems to me in general that HTTP 1.0
level caching should:
1. Always include a last-modified header showing the last checkin time for a
resource.
2. Set the expires/cache-control headers to show when a resource can or
cannot be cached.
Any cache that is using last-modified should also obey cache-control or
expires. Therefore a simple pre-1.0 fix seems to be to set last-modified and
always set cache-control: no-cache and expires headers so nothing will
actually cache the resources. At some later stage it would be possible to
work out what could be cached.
This would solve my use-case 2) problem (overly aggressive caching is
occuring because of lack of last-modified headers) and hopefully wouldn't
cause too many new issues.
Regards,
Damon.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 12 11:22:43 2003