Streaming Header Compression

During the HTTP/QUIC header compression discussions, we've been discussing whether there's a requirement to have streaming / single-pass header compressors or if it's reasonable to assume that an encoder has access to the full header set at once.  I know during the HPACK design process, streaming decoders were a priority, but I don't recall anything about streaming encoders.  So I'd like to consult the HTTP community to see whether implementations have requirements around this.

Because HEADERS frames are length-prefixed, you have to know the full content of the frame before you can send any of it.  In HTTP/2, there is a way around this - CONTINUATION frames can be used for subsequent chunks as you generate them.  However, I don't know that I've heard of anyone using CONTINUATION for this purpose.

In HTTP/QUIC, we've removed CONTINUATION frames in favor of much larger frame lengths, and to general approval because CONTINUATION was a source of bugs and angst.  However, that means it's no longer possible to write the beginning of the frame without having seen and processed the entire header set.  Is that a change we need to revisit?