On Wed, Mar 9, 2011 at 06:43, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Philip Martin <philip.martin_at_wandisco.com> writes:
>> Greg Stein <gstein_at_gmail.com> writes:
>>> The proxy is the one altering the request/response flow. From the
>>> server's standpoint, the client (in this case, the proxy) already
>>> knows the name. Why should the server tell it what it already knows?
>>> Why should it put that useless information onto the wire?
>> It's convenient to implement it that way, a very simple change in the
>> client send path allows testing the client recieve path. If the server
>> doesn't send the header then testing will require a more complicated
>> client change, or the use of a proxy that sends the header.
Wait a minute. The svn client won't ever send this. So I'm not sure
what you mean by "client send path" here, or "requiring ... the use of
Your request for this feature is entirely predicated on a proxy. So of
course you need a proxy. And the client is never sending this header.
> And it may be more convenient for the proxy as well, but I've not looked
> at any proxy implementations so I can't say for certain.
What?! You must be looking at a proxy implementation. That is why you
want this feature.
I don't get it. First you mention "a proxy wants to do this, so I need
<this>", and then you say "but I haven't looked at proxies".
This seems inconsistent.
Received on 2011-03-09 13:07:33 CET