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

Re: WebDAV proxy feature "negotiation" -- there's *got* to be a better way.

From: Mark Phippard <markphip_at_gmail.com>
Date: Tue, 19 Feb 2013 10:54:36 -0500

On Tue, Feb 19, 2013 at 10:43 AM, Daniel Shahaf <danielsh_at_apache.org> wrote:

>> We needed this information in Subversion Edge so that we could
>> configure a slave correctly. In our case, we only knew the master was
>> either running 1.6 or 1.7 so we just send the master an HTTP request
>> to figure out if it supports HTTPv2. If it does, then we know it is
>> running 1.7. We will obviously needed to adjust this for 1.8 and also
>> look for some of the new capabilities.
>>
>
> Therefore, disclosing "%d.%d" % (SVN_VER_MAJOR, SVN_VER_MINOR)
> might not be a problem?

If we are going to base this on the Apache directives that control
this disclosure, then isn't this information already available in the
HTTP headers? Could the slave just make an HTTP request to the master
and parse it out? In my case, the servers are all configured to not
disclose this information so I would still need the explicit
directive.

> Sure, caching would be useful. This information very rarely changes.

What I was getting at earlier is that I do not believe caching is
optional. It seems like mod_dav_svn would have to figure this out and
cache it as part of initializing itself. Otherwise, if the client
sends an OPTIONS request to the slave, and the slave in turn is going
to contact the master before replying, you are kind of limiting the
effectiveness of the slave.

Having thought it through in this thread now, I guess if the slave
only did this when there was no explicit directive to tell it the
version of the master, that would be OK. It would just be a trade-off
that the person configuring the slave could decide to make.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2013-02-19 16:55:08 CET

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.