On Wed, Mar 9, 2011 at 06:43, Philip Martin <philip.mar...@wandisco.com> wrote: > Philip Martin <philip.mar...@wandisco.com> writes: > >> Greg Stein <gst...@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 a proxy". 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. -g
