Re: Recovery from decompression failure (was: Re: Cost analysis: (was: Getting to Consensus: CONTINUATION-related issues))

If we support this a first class RST_STREAM error code is probably justified.

Also, how about sending a single SETTINGS frame with two SETTINGS_HEADER_TABLE_SIZE entries (0 and N)?

On Jul 22, 2014, at 8:29 AM, Ilari Liusvaara <> wrote:

> On Mon, Jul 21, 2014 at 09:16:10AM -0400, Michael Sweet wrote:
>> I think perhaps we are too focused on preventing an endpoint from
>> sending headers that are too large (the 0.2% case) and not on
>> interoperability and avoiding dropping the connection at all costs.
>> It may be the simplest course is to require the connection to be
>> torn down, but we might be able to add a "table version" field to
>> HEADERS and PUSH_PROMISE to track which header table was in use by
>> the sender, add the "table version" field to the header table size
>> value that is send in the SETTINGS frame for the receiver to
>> communicate the active version on the receiver, and define a RST_STREAM
>> error code for "wrong header table version" that triggers a re-send.
>> (I'm not sure whether the complexity of a table versioning scheme is
>> necessary for what should be an infrequent exception...)
> I think the following might do the trick already:
> - Keep counter of sent non-ack SETTINGS frames (settings_sent), initially 0.
> - Keep counter of received SETTINGS ack frames (settings_acked), initially 0.
> - Keep recovery threshold (recovery_threshold), initially 0.
> - If on receiving HEADERS/PUSH_PROMISE, settings_acked < recovery_threshold, then:
>  * reset the stream (REFUSED_STREAM?)
>  * Discard the received header block (including any possible CONTINUATION).
>  * End processing HEADERS/PUSH_PROMISE.
> - Otherwise If HEADERS/PUSH_PROMISE decompression fails, then:
>  * Send one SETTINGS block containg:
>  * Set recovery_threshold <- settings_sent  (includes the SETTINGS just sent).
>  * Discard the rest of the header block (including any possible CONTINUATION).
>  * Reset the stream (DECOMPRESSION_ERROR?) or 431 it.
>  * End processing HEADERS/PUSH_PROMISE.
> -Ilari

Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Tuesday, 22 July 2014 12:36:42 UTC