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

Re: HTTP GET doesn't do keyword replacement?

From: Julian Reschke <julian.reschke_at_gmx.de>
Date: 2003-12-20 11:43:17 CET

Ben Reser wrote:

> The client is responsible for handling keywords, not the server. I know
> I asked this question on IRC a long time ago. The response I got was
> that it would be terribly time consuming for a server to do so, since it
> would have to read through the file looking for the keywords.
>
> For DAV I don't think this would be a huge deal to support, it pretty
> much has to read through the file to send it anyway. The only downside
> would be that in order to send the proper Content-Length we'd have to do
> so before sending the initial header response.
>
> Additionally, we'd need a way to detect svn clients from web browsers.
> One way we could do that was simply by the User-Agent they send. I'm
> not sure if we're sending some other information to be able to detect
> browsers from real svn clients or not.
> ...

In which case you'll have to ensure that the server marks the response
to these two types of GETs as to vary with the User-Agent header
(otherwise, you will confuse caches). Varying on the User-Agent header
really seems to be a bad bad idea, in particular given the fact that
IE's handling of the Vary header is known to be broken.

I think it's much cleaner to treat all GET requests the same way. If
there's some keyword expansion a svn-aware client wants to trigger, it
should do that through an additional request header.

Julian R.

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 20 11:44:30 2003

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

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