Ryan Bloom wrote:
>...
> While that will work for Pound, what are you going to do the first time
> somebody reports the same exact problem with a non-open source proxy?
Recommend they switch to Pound :-)
Also, please remember that this only affects proxies that change the
transport (i.e. change the scheme).
> There are a lot of load balancers that aren't going to modify the
> destination header for you. And even worse, are the simplistic load
> balancing situations using mod_rewrite, which _can't_ rewrite the header.
I'd venture that they aren't doing all the work that Pound is. I'd
also venture they aren't changing the scheme, which is the root of the
problem here.
> Yes, the proxy caused the problem, but mod_dav is going to end up fixing
> it at some point. Does it suck, yeah. But bite the bullet and do it,
> because this is an easy fix that makes subversion work with all proxies
> instead of requiring every proxy to fix a bug that they are all likely to
> have.
Actually, I really don't want or intend to "fix" this. I do like your
suggestion as a pragmatic way to solve it, but I think it overlaps
with the ServerAlias too much, and (in the long run) should not be
necessary.
In the current drafts for revising RFC 2518 (the WebDAV spec), the
Destination: header has been relaxed to allow an abs_path rather than
a full URI. This means that it is possible to drop the scheme, host,
and port from the URI.
That said, I believe that is only a hack to "fix" the problem. The
core issue here is that the URL space identified by "http" could be
*VERY* different from the space identified by "https". Thus, a client
will never presuppose that it can refer to both using the same
abs_path. In this case, it *isn't* because it sees only the space
presented by the Pound proxy. And, as stated, since Pound is modifying
the requests to an origin server to establish that space, it needs to
take all proper precautions when doing so.
Please read the introduction section 13 of the RFC 2616, and its
concepts of semantic transparency. Pound (and other proxies which
rewrite URLs) are going to have to deal with altering URLs contained
within REPORT bodies and 207 (Multistatus) response bodies. Any of
those might be absolute URLs. To maintain the proper transparency,
then Pound will need to do the appropriate rewriting.
Of course, that said: the proxy can save a heap of compute-time and
rewrite-time if we enable a "DAVAlias" type of feature in mod_dav. Or
better yet: the full Apache server. (I see no reason we couldn't,
wouldn't, or shouldn't just expand the ServerAlias directive)
> The closest thing that I could find like the destination header is the
> content-location header, except that it is allowed to specify a relative
> URI. If destination had been allowed to specify a relative URI, you
> wouldn't have this problem, but it isn't, so you do. I think this is one
In the future, it won't be a problem. We can certainly relax
Subversion since we have a matched client/server, but (in general) it
will be a while before clients can switch to an abs_path style (if it
makes sense; per above, I think it will just encourage proxies to be
lazy and not Do The Right Thing, potentially affecting the semantics
of pulling data off the origin server).
> of those cases where it would be far better to be lenient in what you
> accept than to ask every proxy author to try to modify their existing
> products.
Well, we don't want to be "lenient" because that could be erroneous.
If we were *configured* to interpret the alternate space, then that
would be a whole separate matter.
> Remember, than older proxy servers aren't going to know
> anything about the Destination header, and are thus far less likely to be
> able to modify it correctly.
Those older proxy servers will probably not be changing the scheme
either, which is the basis for the problem here.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 26 23:52:42 2003