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

[Dmitri Tikhonov <[e-mail]>]

In our QPACK implementation, [ls-qpack](https://github.com/litespeedtech/ls-qpack), the decoder consumes header block as a stream.  Hence, having a header block of an unspecified size is no problem -- there is no buffering either way.

For QPACK encoder, it is a profitable optimization to be able to write some header blocks directly to the stream.  I share @RyanAtGoogle's emotions in this regard.

@kazuho writes:
> 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.

Isn't this as simple as foregoing the initial size check and closing the connection if you do hit the internal limit?  Certainly, if you're willing to buffer 16KB - 1 bytes to process a frame, you should be willing to buffer 16KB -1 bytes and then throw them out and close the connection.

-- 
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-431568943