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

[Daniel Shahaf <da...@apache.org>]

Mark Phippard wrote on Tue, Feb 19, 2013 at 10:24:03 -0500:
> On Tue, Feb 19, 2013 at 9:09 AM, Daniel Shahaf <da...@apache.org> wrote:
> > Reviving an old thread: has anyone evaluated the possibility of having the
> > slave ask the master for its version at runtime?
> 
> I have considered asking for that before, but I held off because if
> this were possible wouldn't that be considered a security violation?
> Isn't that why httpd has directives like ServerSignature and
> ServerTokens so that the server will not reveal its version
> information easily?
> 

It's not a major problem, and if it is we can just disable it and
require the directive to be specified on the slave when the master has
ServerSignature disabled.

> 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?

> I guess it would be nice if mod_dav_svn could do this probing itself
> upon startup or something and then cache it.  Obviously it cannot do
> it as part of the actual proxying as that would be too late.
> 

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

> 
> > The actual use-case driving this is Philip's workflow.  He commits to
> > svn.apache.org via a DAV proxy on his workstation; but when his proxy runs 1.8,
> > he needs to set "SVMasterVersion 1.7" in his config --- which would get out of date as soon as svn.apache.org is
> > upgraded.
> 
> Is this really a problem?  It is not like the configuration cannot be
> updated when this happens.  If we can make it better great, but I
> would think he would still have to restart his server to even trigger
> whatever code would do this sort of checking.  I cannot envision any

Whether he'll have to restart depends on how we do caching.

> usable proxy scenario that can be totally dynamic.
> 
> -- 
> Thanks
> 
> Mark Phippard
> http://markphip.blogspot.com/

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

[Mark Phippard <ma...@gmail.com>]

On Tue, Feb 19, 2013 at 10:43 AM, Daniel Shahaf <da...@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/