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

Re: Negotiating compression

From: Simone Bordet <simone.bordet@gmail.com>
Date: Wed, 28 May 2014 11:41:38 +0200
Message-ID: <CAFWmRJ0QOLwYeGo3O=eDKpES37vbpgR8GCPA5cdfp-tGAva+gQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>

On Tue, May 27, 2014 at 7:54 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> The long and rambling thread on schedule has again started to discuss
> HPACK.  A point was made regarding negotiation for its use.
> I don't think that negotiation is necessary.  The argument regarding
> the physics, which would dictate the use of an entire RTT for
> negotiation, is compelling, but I have others.  The only reason you
> want negotiation is if you want to be able to influence the behaviour
> of a counterparty.
> A sizable advantage can be gained by modifying your own behaviour,
> which HPACK always permits.  Given that the data you care most about
> protecting is usually the stuff that you send, I'm willing to bet that
> this is good enough in the unlikely event that an attack is
> discovered.

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) ?

Also, if a different, better, header compression algorithm is found,
that also would require a HTTP version bump ?

I'd really like to be as confident as you are, but I'd like to have a
plan B for one of the most used protocols in the world.
So far, IIUC, there is no plan B, right ?

Simone Bordet
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 Wednesday, 28 May 2014 09:42:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC