Re: [hybi] Are HTTP bodies allowed in Websocket client handshakes?

[Andy Green <[e-mail]>]

On 11/1/23 08:16, Philipp Serafin wrote:

> Isn't the upgrade request still technically a  GET request? If so I'd 
> say this already prohibits the client from sending any body.

If it's written anywhere about the GET / UPGRADE relationship maybe so.

I took the question to be about how to deal with an UPGRADE with a body 
turning up if it's going to turn up, maliciously, legally or wrongly.

Not sure it's a big crisis but it does seem to have some space for 
making trouble not spelling it out what to do with it, (if it actually 
isn't spelt out somewhere else) Eg seeing such a thing, intermediaries 
that inspect the stream might be left in a state different than the 
endpoint, if they deal with it differently, eg it's data going out to a 
peer that an intermediary that's supposed to scan fails to look at etc.

I think for example lws will handle UPGRADE differently than other 
methods that might have a body and ignore it atm FWIW, if so it'll be 
treated as coalesced first ws content from the client or pipelined next 
transaction if unsuccessful on pipelined connection, that doesn't sound 
great from an intermediary smuggling pov if so.  It'd be better to hang 
up on any upgrades with bodies.

-Andy

> Andy Green <[e-mail] <mailto:[e-mail]>> schrieb am Mi., 
> 1. Nov. 2023, 08:26:
> 
> 
> 
>     On 10/31/23 22:22, Emile Cormier wrote:
>      > Hi,
>      >
>      > As per the subject, are HTTP bodies allowed in Websocket client
>      > handshakes? Should the server ignore them, or treat their
>     presence as a
>      > protocol error? Web searches don't bring up anything about this
>     question.
> 
>     At the time of the UPGRADE request, the connection is purely http
>     still,
>     so whatever you can send with UPGRADE and how to send it there is
>     defined outside of ws.
> 
>     https://datatracker.ietf.org/doc/html/rfc9110#name-upgrade
>     <https://datatracker.ietf.org/doc/html/rfc9110#name-upgrade>
> 
>     doesn't seem to talk about if you can send a body either, however it
>     does say
> 
>         A client cannot begin using an upgraded protocol on the connection
>         until it has completely sent the request message (i.e., the client
>         can't change the protocol it is sending in the middle of a message).
> 
>     "completely sent the request message" sounds like it would include any
>     pointless body that went out with the request message IIUI, implying
>     the
>     server should swallow the body before replying.  IOW "UPGRADE request"
>     includes any redundant body sent with it.
> 
>     In the case that the upgrade succeeds, data after the "UPGRADE request"
>     will switch to ws protocol.  The server will interpret any data after
>     the "UPGRADE request" as ws protocol data.
> 
>        - UPGRADE req no body -> server doesn't consume body -> OK
>        - UPGRADE req no body -> server consumes body -> OK
>        - UPGRADE req + body -> server doesn't consume body -> broken conn
>        - UPGRADE req no body -> server consumes body -> OK
> 
>     In the case the upgrade is denied, the connection remains in http.
>     There shouldn't be any leftover unconsumed body from the earlier failed
>     UPGRADE request to pipeline into as the next transaction, so again it
>     seems the server should eat any body with the upgrade request before
>     replying.
> 
>     At least, that's my understanding.
> 
>      > The RFC only uses the term "body" in relation to close, ping, and
>     pong
>      > frames
>     -Andy
> 
>      > Cheers,
>      > Emile Cormier
>      >
>      > _______________________________________________
>      > hybi mailing list
>      > [e-mail] <mailto:[e-mail]>
>      > https://www.ietf.org/mailman/listinfo/hybi
>     <https://www.ietf.org/mailman/listinfo/hybi>
> 
>     _______________________________________________
>     hybi mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/hybi
>     <https://www.ietf.org/mailman/listinfo/hybi>
>