HTTP2 Expression of Interest

This expression of interest supports our HTTP Speed+Mobility proposal as a starting point for HTTP 2.0.





"briefly describe your implementation or deployment before giving your feedback on all of the proposals"



We have client and server stacks for HTTP 1.1 and associated APIs, with massive deployment in consumer scenarios, corporate and large organizations, cloud, etc. We use HTTP in many different ways and scenarios, including browsers and client apps, web servers and web services, media delivery, cloud applications, VPN, and many others.



"Have you already implemented / deployed this proposal? Do you intend to?"



We have implemented HTTP S+M, and the prototype is up to date with our latest specification release. Please refer to the relevant blog for highlights as well as to obtain the prototype, including source code:



http://blogs.msdn.com/b/interoperability/archive/2012/07/05/check-out-the-updated-http-speed-mobility-open-source-prototype.aspx



"Do you believe it is a good basis for standardization? Why / why not?"



Yes. This proposal addresses the goals that HTTPbis has set for HTTP 2.0 but does so while rooted on a set of principles we believe to be essential for the WG, the IETF and general applicability of HTTP: maintain HTTP semantics, reuse existing standards when possible, be broadly applicable, account for modern clients, etc.



For a summary of those principles please refer to:

http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility-02#section-1.1



"If it is adopted as the basis for further work, what concerns need to be addressed?"



Regardless of which of the three proposals is selected as the starting point, HTTP 2.0 has to address different issues which the WG must discuss and ultimately decide on.



This amounts to a PROBLEM STATEMENT for HTTP 2.0. Our current thinking about such a problem statement is below. For each of the topics we summarize our current position, but the main point is that the WG should discuss the issues and arrive at agreed-upon positions for each of these.



Problem Statement for HTTP 2.0.

1.       Negotiation: Setting up an instance of HTTP 2.0.



Our position: We believe in enabling a secure web, but we also believe that to meet the principle of broad applicability, there cannot be a hard dependency on TLS/SSL.  Accordingly, the negotiation must work for both "https" (over TLS) and "http" (no TLS).  We use HTTP Upgrade, which was originally meant for this purpose.



2.       Session Layer: This defines framing and maintenance of the HTTP 2.0 instance.



Our position: Our proposal reuses Websockets binary framing.



3.       Multiplexing Layer: This defines multiplexing HTTP requests over a single TCP connection and maintenance of the multiplexing layer, including flow control.



Our position: We are intrigued by the idea of using multiplexing to enable parallel download of multiple resource, to reduce the TCP overhead on content servers and to reduce the need for domain sharding. We would like to have a data-driven discussion of how much actual efficiency can be gained through multiplexing, whether those gains can be obtained with sites that already use sharding, and whether the gains are worth the cost in complexity.

Flow Control: We believe that flow control is necessary with any MUX solution, but that flow control must be simple and should allow for full bandwidth utilization by default.



4.       HTTP layering: How HTTP messages are layered over the above framing and multiplexing.



Our position: We agree with reducing the overhead of headers in HTTP, either through compression or binary encoding. We think that compression is simple to implement but are open to discussing binary encoding methods suggested by proposals such as draft-tarreau-httpbis-network-friendly-00.

Beyond HTTP 2.0:

-          Server push or Client pull: We are interested in exploring server push or client pull as a separate specification from HTTP 2.0, one that ideally should work for HTTP 1.1 as well.



Thank you,



Rob