- From: Simone Bordet <simone.bordet@gmail.com>
- Date: Wed, 28 May 2014 11:41:38 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi, 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 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 Wednesday, 28 May 2014 09:42:07 UTC