Abstract
This document describes an Upgrade-based protocol negotiation
proposal for HTTP 2.0.
1. Introduction
User agents interact with numerous servers from different domains
using different versions of HTTP. In particular, the co-existence of
HTTP/1.x and HTTP/2.x requires a protocol negotiation mechanism
transparent to the user agents. This document specifies an Upgrade-
based HTTP 2.0 connection negotiation.
HTTP/2.0 will have the capability (but not the requirement) to use
the same ports as HTTP/1.X, typically, but not limited to, 80 (in the
clear) and 443 (when over TLS/SSL). Of course, it is possible for a
client to somehow acquire knowledge that a server implements HTTP/2.0
at a given port. In such a case, the client can immediately begin
sending HTTP/2.0 binary frames to the server, and the server can
immediately respond with the corresponding HTTP/2.0 frames. How that
knowledge is acquired is not the subject of this note. It could be
acquired by some out-of-band means such as using the DNS, or by some
configuration prior to the HTTP/2.0 exchange. Or it could have been
aquired earlier in-band in a previous exchange using, for example,
the Upgrade-based mechanism specified in this document. It could
have also been acquired at an earlier phase of this same exchange,
for example, at a lower protocol layer that precedes the overall HTTP
sequence, such as in the TLS handshake (if using TLS).
Nevertheless, there may be some situations, in which the client can
only assume that a server speaks HTTP/1.X. In such cases, a
connection upgrade mechanism to opportunistically attempt switching
to HTTP/2.0 is essential. Otherwise, the exchange will remain at
HTTP/1.X despite both client and server being willing to speak
HTTP/2.0.
This document specifies such a connection upgrade for HTTP/2.0. This
handshake does not incur any extra delay in obtaining a response in
HTTP/2.0, as the protocol switch is immediate and effective within
the first round trip. There is no delay either if there is no
protocol switch, as the server is capable to respond via HTTP/1.1
also within the first initial round trip.
This handshake uses the Upgrade header defined in HTTP/1.1
[I-D.ietf-httpbis-p1-messaging]. This Upgrade header is also in wide
use by the WebSocket protocol for similar purposes [RFC6455].
The goal of this document is to propose additional text to the
HTTP/2.0 specification. The starting point for HTTP/2.0, the initial
version of [I-D.ietf-httpbis-http2], has no language with respect to
a connection upgrade procedure. Hence, the text below could be
incorporated as a new section or sections within the HTTP/2.0
document.
read more.......http://tools.ietf.org/html/draft-montenegro-httpbis-http2-negotiation-01