Hi Lucas, see below.
From: Lucas Pardue <[email protected]> Date: Friday, 16. October 2020 at 21:35 To: Mirja Kuehlewind <[email protected]> Cc: David Schinazi <[email protected]>, Mike Bishop <[email protected]>, QUIC WG <[email protected]>, MASQUE <[email protected]> Subject: Re: [Masque] HTTP DATA frames for HTTP CONNECT? Hey, On Fri, 16 Oct 2020, 20:09 Mirja Kuehlewind, <[email protected]<mailto:[email protected]>> wrote: Not sure I understand this correctly. Without the DATA framing you would not need any frame parsing anymore, you only have to remember that a certain stream is converted into a forwarding stream and blinding forward all payload from that stream. The whole point is that then no additional HTTP logic would be need anymore. So with quiche, a receiving endpoint calls quiche's HTTP/3 oriented poll() method. This reads from a transport stream and does HTTP/3 syntax handling e.g. checking that streams and frames are being used according too all the rules in the H3 spec. Beyond that quiche doesn't handle anything about the semantics such as request processing; thats the application's job. With a modified CONNECT definition, it doesn't change things for other types of request. I still need to do frame parsing on streams unless an application tells me otherwise. I don’t know the details of your implementation and I didn’t check, so maybe I’m just misunderstand but I would assume that the CONNECT handling itself is done by the HTTP implementation and not the application on top. So your HTTP connection would receive a CONNECT (& convert that stream into a tunnel) and then tell the application that a connect was received. Then when you receive any data on that stream you can forward it directly to the application without even using the frame parser given you have the state information which streams have seen a CONNECT with the HTTP stack. Did you implement CONNECT already? On the send side, I'd need the mirror that allows an application to request sending unframed data. What I’m saying is that you have ne a separate interface to generate the CONNECT (again assuming actually generating the CONNECT this is part of your HTTP stack and not the part of the application). This method should than generate a handle that allows you to send unframed data only on that stream (where you are sure that a CONNECT was send and confirmed previously). That causes a bled across my separation of concerns boundary. I need to account for applications that might misuse this capability to send unframed data either accidently, or purposefully because they wish to do side step the quiche's frame checking. If you can ensure that your HTTP has initial send a CONNECT (and got a 200 reply) on that stream, I don’t think you need any additional checking. These complications make me nervous. Others might have a different risk assessment. Cheers Lucas
