On 26 Aug 2003, Ben Collins-Sussman wrote:
> <firstname.lastname@example.org> writes:
> > So instead, mod_dav is going to need to provide a directive somewhat
> > analagous to alias. Essentially allowing mod_dav to rewrite a
> > Destination header to remove proxy information.
> I just had a chat with Greg Stein about this, and we don't like this
> idea. It was the proxy that rewrote the URLs, and didn't do the whole
> job. It should be rewriting the Destination: header as well. "If you
> broke it, you fix it" -- it's not mod_dav's job to clean up up after
> the proxy's mess.
> Pound is open-source, so it seems quite likely that it can be fixed
> relatively easily.
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?
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.
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
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
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. 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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Aug 26 22:37:42 2003