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

Fwd: HTTP2 Expression of Interest [twitter]

From: Mark Nottingham <mnot@mnot.net>
Date: Sun, 15 Jul 2012 10:21:18 +1000
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <CC798B0E-F613-4758-96EE-BC32957A09AD@mnot.net>


Begin forwarded message:

> From: Jeff Pinner <jpinner@twitter.com>
> Subject: HTTP2 Expression of Interest
> Date: 14 July 2012 11:35:06 AM AEST
> To: mnot@mnot.net
> 
> Hi Mark,
> 
> Below is Twitter's response to the HTTP/2.0 Expression of Interest.
> Could you please forward it to the HTTPbis working group list.
> 
> Sincerely,
> Jeff Pinner
> Twitter, Inc.
> 
> 
> This is Twitter's response to the call for expressions of interest:
> http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2CfI
> 
> 1. Introduction
> 
> Twitter brings people closer to the things they care about.
> 
> Twitter has implemented, deployed, and open sourced both the SPDY/v2
> and SPDY/v3 protocols and is interested in sharing our experience as
> well as participating in the development and eventual standardization
> of HTTP/2.0.
> 
> 2. Criteria for HTTP/2.0
> 
> 2.1 Multiplexing
> 
> In order to improve the performance of HTTP, we believe that
> multiplexing should be incorporated into the HTTP/2.0 specification.
> The performance gains achievable by the reduction in connection
> overhead, the pipelining of requests, and the ability to deliver
> responses out of order address many of the limitations of the HTTP/1.1
> specification. Multiplexing also helps alleviate the need for complex
> performance optimizations that attempt to work around these
> limitations.
> 
> 2.2 Encryption
> 
> Twitter strongly believes that the HTTP/2.0 specification should
> mandate transport layer encryption. The exchange of personal
> information across the web is only expected to increase, and the
> privacy and security afforded by encryption at the transport layer
> outweighs any difficulties in the implementation.
> 
> Twitter aims to secure all communication with its users, and is doing
> so using commodity hardware and openly-available software. We believe
> that the various reasons provided for not requiring protocol
> encryption are poor security practice, and that the necessary
> improvements to TLS and the CA model should not prevent encryption
> from being mandated in HTTP/2.0. Requiring encryption in the protocol
> is a step that protects against insecure design via omission or
> oversight.
> 
> 3. Assessment of the SPDY Protocol
> 
> 3.1 Multiplexing
> 
> SPDY provides multiplexing support that allows for both request
> pipelining and out-of-order response delivery. Coupled with request
> priority and per-stream flow control, this provides an effective
> mechanism to overcome many performance limitations of the HTTP/1.1
> specification.
> 
> 3.2 Compression
> 
> SPDY mandates the use of compression for the HTTP headers. We have
> found significant performance improvements due to the resulting
> reduction in message size and recommend that compression be mandated
> in the HTTP/2.0 specification. However, the additional benefit
> achieved through the use of the compression dictionary appears to only
> affect the initial message and thus does not seem to outweigh the
> additional complexity. We recommend that its adoption be more
> carefully considered.
> 
> 3.3 Versioning
> 
> The versioning scheme in the SPDY protocol is incomplete and is
> redundant when using NPN to negotiate the protocol.
> 
> 3.4 TLS
> 
> The SPDY protocol does not mandate the use of TLS, however most
> implementations negotiate the protocol using the NPN TLS extension. We
> recommend that the use of TLS be mandated and that the protocol be
> made compatible with the SNI TLS extension.
> 
> 4. Summary
> 
> Twitter recommends that the SPDY protocol be used as the basis for
> further work and eventual standardization as the HTTP/2.0
> specification with the additional requirement that transport layer
> encryption be mandated.

--
Mark Nottingham   http://www.mnot.net/
Received on Sunday, 15 July 2012 00:21:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 15 July 2012 00:22:02 GMT