W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

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

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Tue, 22 Jul 2014 15:29:02 +0300
To: Michael Sweet <msweet@apple.com>
Cc: Roberto Peon <grmocg@gmail.com>, Jason Greene <jason.greene@redhat.com>, David Krauss <potswa@gmail.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>, Mark Nottingham <mnot@mnot.net>
Message-ID: <20140722122901.GA32429@LK-Perkele-VII>
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.

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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC