Hi Lucas,

see inline.

From: Lucas Pardue <[email protected]>
Date: Friday, 16. October 2020 at 13:25
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?


On Fri, 16 Oct 2020, 09:45 Mirja Kuehlewind, 
<[email protected]<mailto:[email protected]>>
 wrote:
Hi David,

I was sending this request to exactly understand if or what the issues 
are/could be in not having the DATA frame. Can you maybe further explain which 
issue you see?
I can't speak for David but the issues I forsee come from additional code paths 
needed to support the feature. The frame parsing code needs to become HTTP 
method-aware, which is not the case in the implementation I own.

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.

With QUIC chair hat on: this is very late to be proposing design changes. It 
might even be too late. I'm setting a high bar here for compelling evidence or 
support that something needs to be changed.

I know… that’s why I’m trying to understand the implications instead of just 
raising an issue on github.

Mirja


Cheers
Lucas



masque<https://www.ietf.org/mailman/listinfo/masque>

Reply via email to