Re: Clarification for RFC7231 CONNECT (section 4.3.6)

On Wed, Apr 29, 2015 at 06:27:17PM +1200, Amos Jeffries wrote:
> On 29/04/2015 5:13 p.m., Willy Tarreau wrote:
> > On Wed, Apr 29, 2015 at 05:09:11AM +0000, Adrien de Croy wrote:
> >>
> >> I've also seen clients send bodies on CONNECT requests...
> > 
> > Seen it as well.
> > 
> >> It's not clear what is supposed to happen, but IME if you pass it 
> >> through, then things don't work, so currently we silently swallow it.
> > 
> > In the case I've seen, the body in question was in fact the contents
> > supposed to be sent. Similarly I think they were advertising a body
> > to ensure broken intermediaries would correctly transfer the data.
> > Just like the good old time where it was easy to SSH home via a proxy
> > by sending a POST with a large body :-)
> > 
> 
> Squid used to have that silent-drop behaviour. Then we got complaints
> about VoIP audio codecs being screwed up. Nowdays it appears to be SPDY
> or WebSockets handshakes occuring in the first packet.
> 
> Based on that experience I expect people to start seeing CONNECT +
> HTTP/2 SETTINGS frame in one packet shortly (if not already).

Thanks folks, this is very useful information.  It seems the client I
was talking about then has two bugs, not one, and I'll be fixing one of
them independently of the other.

(The bug I'll be fixing is that the client throws away any data read
along with the 2xx CONNECT response, which breaks SSH in a racy way.
The other bug is that it throws away the 2xx CONNECT response instead of
prepending it to the server->client tunneled stream.  These two bugs are
independent of each other.  The first bug is the urgent one for me.)

Nico
--

Received on Wednesday, 29 April 2015 16:45:09 UTC