Permalink
Browse files

Clarifying upgrade options (#1).

  • Loading branch information...
1 parent 8ed0325 commit 1ef211d5f7ff47d6146d62160cda644a0b4898bd @martinthomson martinthomson committed Feb 28, 2013
Showing with 19 additions and 13 deletions.
  1. +19 −13 draft-ietf-httpbis-http2.xml
@@ -314,29 +314,35 @@
Once the server returns the 101 response, both the client and the server send a <xref
target="SessionHeader">session header</xref>.
</t>
-
- <t>
- A client can learn that a particular server supports HTTP/2.0 by other means. A client
- MAY immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0.
- [[Issue #29: This is not definite. We may yet choose to perform negotiation for every
- connection. Reasons include intermediaries; phased upgrade of load-balanced server farms;
- etc...]] [[Issue #1: We need to enumerate the ways that clients can learn of HTTP/2.0
- support.]]
- </t>
</section>
+
<section anchor="discover-https" title="Starting HTTP/2.0 for &quot;https:&quot; URIs">
<t>
A client that makes a request to an "https:" URI without prior knowledge about support for
- HTTP/2.0 uses TLS with <xref target="TLSNPN">TLS-NPN</xref> extension. [[TBD, maybe NPN]]
+ HTTP/2.0 uses TLS with <xref target="TLSNPN">TLS-NPN</xref> extension. [[TBD, maybe ALPN]]
</t>
<t>
Once TLS negotiation is complete, both the client and the server send a <xref
target="SessionHeader">session header</xref>.
</t>
+ </section>
+ <section anchor="known-http" title="Starting HTTP/2.0 with Prior Knowledge">
+ <t>
+ A client can learn that a particular server supports HTTP/2.0 by other means. A client
+ MAY immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0. This
+ only affects the resolution of "http:" URIs, servers supporting HTTP/2.0 are required to
+ support <xref target="TLSNPN">protocol negotiation in TLS</xref>.
+ </t>
+ <t>
+ Prior support for HTTP/2.0 is not a strong signal that a given server will support
+ HTTP/2.0 for future sessions. It is possible for server configurations to change or for
+ configurations to differ between instances in clustered server. Different "transparent"
+ intermediaries - intermediaries that are not explicitly selected by either client or
+ server - are another source of variability.
+ </t>
</section>
-
</section>
<section anchor="FramingLayer" title="HTTP/2.0 Framing Layer">
@@ -1345,8 +1351,8 @@
<t>
When a HTTP/2.0 connection is first established, new streams are created with an
initial flow control window size of 65535 bytes. The session flow control window is
- also 65536 bytes. Both endpoints can adjust the initial window size for new streams
- by including a value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that forms
+ 65536 bytes. Both endpoints can adjust the initial window size for new streams by
+ including a value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that forms
part of the session header.
</t>
<t>

0 comments on commit 1ef211d

Please sign in to comment.