RE: #466 segment compression

On 02 May 2014 00:01, I wrote:
> On 29 April 2014 21:57, grmocg@gmail.com wrote:
>> If compression is per-segment as opposed to per-frame
>>    AND we wish to restrict the amount of state the server must keep around
>>    AND the sender wishes to have all the data in the segment compressed
>>   THEN then the segment being compressed must be sent in its entirety in a contiguous series of frames with > no muxing of other streams in the middle.
>
> The exact same problem exists for dynamic compression with C-E.  How are you going to solve that?

Sorry to reply to my own e-mail, but I really think this does apply to dynamic C-E compression and is a DoS vector.

Suppose a client sends N request for various entities that are dynamically compressed, where N=MAX_CONCURRENT_STREAMS and suggests an equal priority for each. If the server gives equal priority to serving each stream, it will have N outsanding compression contexts until all requests are serviced. By contrast, in HTTP/1.1, even with pipelining, a single client on a single connection would only ever require one compression context on the server to service its requests.

This is an argument in favor of using frame-by-frame compression for dynamic compression since frame-by-frame compression _can_ be implemented with only one outstanding compression context at any given time.  It's also an argument for mandating client *support* for frame-by-frame gzip (i.e. non-optional) because it always gives servers a way out from this DoS vector.

Has anybody implemented a native HTTP/2 server with dynamic compression support that can speak to this problem?
This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Thursday, 1 May 2014 22:43:07 UTC