- From: Adrien de Croy <adrien@qbik.com>
- Date: Tue, 29 Nov 2011 23:55:56 +1300
- To: Willy Tarreau <w@1wt.eu>
- CC: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org, Dmitry Kurochkin <dmitry.kurochkin@measurement-factory.com>
I can understand why someone would code some software that way, but I don't think it's correct to call that a proxy. At least it's not HTTP compliant. It could be argued that strategy of proxy operation is simply not valid. Regards Adrien On 29/11/2011 11:48 p.m., Willy Tarreau wrote: > Hi Adrien, > > On Tue, Nov 29, 2011 at 08:51:34PM +1300, Adrien de Croy wrote: >> I don't see it that way. If the intermediary owns the TCP connection to >> the client, it is the emitter. >> >> HTTP explicitly prohibits sending multiple Content-Length headers. >> >> Therefore an intermediary must not send more than one. Regardless of >> what it receives. > It's not only a matter of whether it owns the TCP connection or not, but > also what it does with it. A basic TCP proxy owns the connections too and > becomes the emitter, still it cannot claim to be an HTTP agent and even > less to be able to fix complex protocol issues. > > In my opinion, the difference lies on who produces the contents. If a proxy > builds a complete request from a list of headers, it has no excuse for not > producing them right. If a proxy just buffers TCP payload until it sees a > double CRLF, makes a few checks there and lets them go, we cannot expect it > to fix such issues. > > Of course everything is not that black and white but it is easy to spot > some valid uses of every variations and to act responsibly in every case. > > Regards, > Willy > > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Tuesday, 29 November 2011 10:56:32 UTC