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

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:
    1) SETTINGS_HEADER_TABLE_SIZE 0
    2) SETTINGS_HEADER_TABLE_SIZE <whatever>
  * 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

Received on Tuesday, 22 July 2014 12:29:30 UTC