Re: [quicwg/base-drafts] DATA frame encoding is inefficient for long dynamically generated bodies (#1885)

[Kazuho Oku <[e-mail]>]

@RyanAtGoogle
> how would this proposal prevent an implementation from capping the maximum size of a frame?

It doesn't. However, introducing the concept of non-DATA frames terminated by EOS has a impact on complexity. We handle HQ frames in the following way:
* We keep the frame header in the receive buffer until all the header is delivered. Then,
* if it is a DATA frame, we pop the frame header from the receive buffer, and continue reading the data out from the receive buffer until we read the exact amount of data specified by the frame header
* if it is not a DATA frame, we check that the size of the frame is below 16KB. If it is above that, we issue a connection close. If it is below that, we keep the octets in the receive buffer until the entire frame arrives. Once the frame arrives, we process it in-place, then remove it from the receive buffer.

Having non-DATA frames terminated by EOS means that we need add a different path for the last bullet. I'm sure I can implement that, but my preference goes to avoiding it.

I can understand the motivation to use EOS as a terminator for DATA frames. It makes sense because you might emit a large number of DATA frames for each HTTP response, and because DATA is typically the last frame type to be sent using a stream. Neither of the two points apply to other frame types, which means that the optimization is far less useful for them, even though I understand the elegance of permitting that for all frame types.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1885#issuecomment-431515701