You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <da...@apache.org> on 2013/02/19 15:09:39 UTC
Re: WebDAV proxy feature "negotiation" -- there's *got* to be a better way.
Reviving an old thread: has anyone evaluated the possibility of having the
slave ask the master for its version at runtime?
Currently we require an "SVNMasterVersion 1.7" directive in the slave's
httpd.conf, but the problem is that the value of that directive can get out of
date as the master is upgraded (or downgraded).
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.
(sidebar: do we promise forward compatibility here? i.e., is
"SVNMasterVersion 1.7" against an in-fact-1.8 master *guaranteed* to work?)
On Mon, Oct 15, 2012 at 08:19:16AM -0400, Mark Phippard wrote:
> On Mon, Oct 15, 2012 at 7:59 AM, C. Michael Pilato <cm...@collab.net> wrote:
>
> > What solutions do we have?
> >
> > - Something automated? Can a slave server contact a master server with
> > a custom feature negotiation request and cache the results?
>
> Is this possible? Could we try to contact the master at server
> startup or something and cache the version somewhere? That said, I do
> not believe the server currently provides any easy way to know this.
> It might even be a security hole if it did.
>
> We needed to know the version of the master in SVN Edge. With 1.7,
> this was relatively easy to do because we just had to see if the
> server supported HTTPv2. As we start to get to more obscure features
> it seems like it will be more difficult.
>
> This would be the ideal though. Maybe this "cache process" could go
> through the same feature negotiation that a client would normally go
> through and figure it out from that?
>
> > - Make the configuration fit the audience? What if instead of a (growing)
> > list of httpd.conf directives which mean nothing to the typical
> > administrator, we simply have one: SVNMasterVersion ${VERSION_NUMBER}?
> > We know which features showed up in which releases, and should be able
> > to do the right thing.
>
> I think this would be the next best option.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
Re: WebDAV proxy feature "negotiation" -- there's *got* to be a
better way.
Posted by 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/
Re: WebDAV proxy feature "negotiation" -- there's *got* to be a
better way.
Posted by 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.
Posted by Philip Martin <ph...@wandisco.com>.
Ben Reser <be...@reser.org> writes:
> On Tue, Feb 19, 2013 at 8:03 AM, Philip Martin
> <ph...@wandisco.com> wrote:
>> When the client sends the OPTIONS request to the proxy mod_dav calls
>> into mod_dav_svn/version.c:get_option. Is it possible for mod_dav_svn
>> to send an OPTIONS request to the master at that stage? I suppose
>> that's a not quite the same as the proxy mechanism used for other
>> requests.
>
> Seems to me this is what you would need to do. Using a configuration
> option signals a need to keep the configuration option in sync with
> the master. If you don't use a configuration option then you
> shouldn't have to maintain anything. If you cache the version on the
> proxy then the proxy needs to be restarted whenever the master
> changes. Which isn't particularly intuitive.
Without really understanding the mirror code I tried to simply proxy the
OPTIONS request:
Index: subversion/mod_dav_svn/mirror.c
===================================================================
--- subversion/mod_dav_svn/mirror.c (revision 1447804)
+++ subversion/mod_dav_svn/mirror.c (working copy)
@@ -88,8 +88,7 @@ int dav_svn__proxy_request_fixup(request_rec *r)
const char *seg;
/* We know we can always safely handle these. */
- if (r->method_number == M_REPORT ||
- r->method_number == M_OPTIONS) {
+ if (r->method_number == M_REPORT) {
return OK;
}
@@ -123,6 +122,7 @@ int dav_svn__proxy_request_fixup(request_rec *r)
if (seg && (r->method_number == M_MERGE ||
r->method_number == M_LOCK ||
r->method_number == M_UNLOCK ||
+ r->method_number == M_OPTIONS ||
ap_strstr_c(seg, special_uri))) {
int rv;
seg += strlen(root_dir);
That does allow me to commit using a 1.8 client through a 1.8 proxy to a
1.7 master without specifying SVNMasterVersion.
It's obviously not a real solution. We cannot simply pass on the
master's OPTIONS response as the master may be newer than the proxy; we
probably need the proxy to do some filtering of the response. Also it
caused ra_serf to segv if the path in the slave Location wasn't
identical to the path in the master Location.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: WebDAV proxy feature "negotiation" -- there's *got* to be a
better way.
Posted by Ben Reser <be...@reser.org>.
On Tue, Feb 19, 2013 at 10:09 AM, Daniel Shahaf <da...@apache.org> wrote:
> How so? If the proxy caches the master version per-process or
> per-connection, it won't need to be restarted to notice master upgrades,
> will it?
Per-connection would be fine but based on the discussion in the thread
I was presuming per-process. Per-process caching doesn't necessarily
have any implied end of the cache since you can run
MaxRequestsPerChild set to zero. Per-connection would be much more
like what Philip is talking about.
Re: WebDAV proxy feature "negotiation" -- there's *got* to be a
better way.
Posted by Daniel Shahaf <da...@apache.org>.
Ben Reser wrote on Tue, Feb 19, 2013 at 09:22:13 -0800:
> On Tue, Feb 19, 2013 at 8:03 AM, Philip Martin
> <ph...@wandisco.com> wrote:
> > When the client sends the OPTIONS request to the proxy mod_dav calls
> > into mod_dav_svn/version.c:get_option. Is it possible for mod_dav_svn
> > to send an OPTIONS request to the master at that stage? I suppose
> > that's a not quite the same as the proxy mechanism used for other
> > requests.
>
> Seems to me this is what you would need to do. Using a configuration
> option signals a need to keep the configuration option in sync with
> the master. If you don't use a configuration option then you
> shouldn't have to maintain anything. If you cache the version on the
> proxy then the proxy needs to be restarted whenever the master
> changes. Which isn't particularly intuitive.
How so? If the proxy caches the master version per-process or
per-connection, it won't need to be restarted to notice master upgrades,
will it?
Re: WebDAV proxy feature "negotiation" -- there's *got* to be a
better way.
Posted by Ben Reser <be...@reser.org>.
On Tue, Feb 19, 2013 at 8:03 AM, Philip Martin
<ph...@wandisco.com> wrote:
> When the client sends the OPTIONS request to the proxy mod_dav calls
> into mod_dav_svn/version.c:get_option. Is it possible for mod_dav_svn
> to send an OPTIONS request to the master at that stage? I suppose
> that's a not quite the same as the proxy mechanism used for other
> requests.
Seems to me this is what you would need to do. Using a configuration
option signals a need to keep the configuration option in sync with
the master. If you don't use a configuration option then you
shouldn't have to maintain anything. If you cache the version on the
proxy then the proxy needs to be restarted whenever the master
changes. Which isn't particularly intuitive.
Re: WebDAV proxy feature "negotiation" -- there's *got* to be a better way.
Posted by Philip Martin <ph...@wandisco.com>.
Mark Phippard <ma...@gmail.com> writes:
> 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.
When the client sends the OPTIONS request to the proxy mod_dav calls
into mod_dav_svn/version.c:get_option. Is it possible for mod_dav_svn
to send an OPTIONS request to the master at that stage? I suppose
that's a not quite the same as the proxy mechanism used for other
requests.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: WebDAV proxy feature "negotiation" -- there's *got* to be a
better way.
Posted by Mark Phippard <ma...@gmail.com>.
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?
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.
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.
> 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
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.
Posted by Daniel Shahaf <da...@apache.org>.
Daniel Shahaf wrote on Tue, Feb 19, 2013 at 14:09:39 +0000:
> Reviving an old thread: has anyone evaluated the possibility of having the
> slave ask the master for its version at runtime?
I've filed http://subversion.tigris.org/issues/show_bug.cgi?id=4324 with
milestone 1.8-consider to track this issue. (And Mike I took the
liberty of CCing you.)