Re: Negotiating compression

Hi,

On Thu, May 29, 2014 at 8:34 AM, Willy Tarreau <w@1wt.eu> wrote:
> On Wed, May 28, 2014 at 10:32:44AM -0700, Martin Thomson wrote:
>> On 28 May 2014 02:41, Simone Bordet <simone.bordet@gmail.com> wrote:
>> > Can you please expand on what is plan B in the unlikely event ?
>> > I am guessing that it would require to bump the HTTP version, and a
>> > worldwide update of all servers to the new version (or drop to HTTP
>> > 1.1) ?
>>
>> That's extreme, but I think reasonable.  Given that you are talking
>> about trying to force behaviour on a counterparty, I don't see there
>> being any virtue in finer grained control over counterparty behaviour.
>
> I tend to think that a failsafe, non-optimal fallback without the bells
> and whistles could significantly drive adoption. Devices could start by
> only supporting this minimal subset, and later implement the large one.
> These ones could be advertised in the ALPN name (h2 = failsafe, h2h =
> hpack version for example) so that we don't need an extra round trip
> to know what is supported.
>
> That way if a CRIME-like attack surfaces, simply disable h2h for the
> time it takes to design a new encoding and applications relying on
> passing everything in the same connection continue to work, just
> slightly slower.
>
> And devices with limited capabilities can only implement the non-optimal
> mode which is cheaper for them.

I wholeheartedly agree with this approach.
There need not to be a full negotiation mechanism, h2 and h2h are
enough for now, and failing that negotiation, fall back to HTTP 1.1.

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

Received on Thursday, 29 May 2014 07:03:28 UTC