Hmmm. We (well, I) moved issue #971 to Post-1.0 when it became clear
that it was no longer a "one hour fix". It's still probably less than
a day, but unfortunately I can't promise we'll get to it before 1.0.
If you can persuade some developer that the change is needed sooner,
that would be great! (I wish I could be that developer, but I'm
committed to resolving other issues first.) Or, if you want to start
sending in patches, and become a developer, then you can do it
yourself eventually... But that may be more involvement than you were
looking for.
Meanwhile, can you put your suggestion
> 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.
into the issue, so at least this first step is described for anyone
who takes a look? Might want to link to your entire mail, too.
-Karl
"Damon Rand" <damon@cybermagic.co.nz> writes:
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 12 18:05:33 2003