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

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

From: Michael Sweet <msweet@apple.com>
Date: Tue, 22 Jul 2014 08:36:09 -0400
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: <84BFD2B4-B9BC-47D6-A219-4D1C2D20CA01@apple.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
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 <ilari.liusvaara@elisanet.fi> 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:
>    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

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Tuesday, 22 July 2014 12:36:42 UTC

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