Skip to content

Instantly share code, notes, and snippets.

Created July 2, 2014 13:41
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
What would you like to do?
proposed patch for HTTP2 issue 535
diff --git a/draft-ietf-httpbis-http2.xml b/draft-ietf-httpbis-http2.xml
index 613d763..3de7ff9 100755
--- a/draft-ietf-httpbis-http2.xml
+++ b/draft-ietf-httpbis-http2.xml
@@ -2676,6 +2676,13 @@ HTTP2-Settings = token68
An HTTP message (request or response) consists of:
<list style="numbers">
+ zero or more <x:ref>HEADERS</x:ref> frames (followed by zero or
+ more <x:ref>CONTINUATION</x:ref> frames) containing the message
+ headers of non-final (1xx) HTTP responses (see <xref target="RFC7230" x:fmt=","
+ x:rel="#header.fields"/> and <xref target="RFC7231" x:fmt=","
+ x:rel="#status.1xx"/>), and
+ </t>
+ <t>
one <x:ref>HEADERS</x:ref> frame (followed by zero or more <x:ref>CONTINUATION</x:ref>
frames) containing the message headers (see <xref target="RFC7230" x:fmt=","
x:rel="#header.fields"/>), and
@@ -2724,11 +2731,12 @@ HTTP2-Settings = token68
<section anchor="informational-responses" title="Informational Responses">
- The 1xx series of HTTP response status codes (<xref target="RFC7231" x:fmt=","
- x:rel="#status.1xx"/>) are not supported in HTTP/2.
+ HTTP/2 removes support for the two 1xx series status codes defined in
+ <xref target="RFC7231" x:fmt="," x:rel="#status.1xx"/>): 100 (Continue),
+ and 101 (Switching Protocols).
- The most common use case for 1xx is using an Expect header field with a <spanx
+ 100 (Continue) was used with the Expect header field with a <spanx
style="verb">100-continue</spanx> token (colloquially, "Expect/continue") to indicate
that the client expects a 100 (Continue) non-final response status code, receipt of
which indicates that the client should continue sending the request body if it has not
@@ -2751,12 +2759,7 @@ HTTP2-Settings = token68
clients, in anticipation of a final status code.
- Other defined 1xx status codes are not applicable to HTTP/2. For example, the semantics
- of 101 (Switching Protocols) aren't suitable to a multiplexed protocol. Likewise, <xref
- target="RFC2518">102 (Processing)</xref> is no longer necessary to ensure connection
- liveness, because HTTP/2 has a separate means of keeping the connection alive. The use
- of the 102 (Processing) status code for progress reporting has since been deprecated and
- is not retained.
+ The semantics of 101 (Switching Protocols) arent't suitable to a multiplexed protocol.
This difference between protocol versions necessitates special handling by
@@ -2776,10 +2779,6 @@ HTTP2-Settings = token68
request that has a body; see <xref target="RFC7231" x:fmt=","
x:rel="#header.expect"/> for specific requirements.
- <t>
- An intermediary that gateways HTTP/2 to HTTP/1.1 MUST discard all other 1xx
- informational responses.
- </t>
@@ -3173,6 +3172,22 @@ HTTP2-Settings = token68
foo = bar
+ <t>
+ A non-final response using a 1xx status code other than 100 or 101
+ is transmitted as a <x:ref>HEADERS</x:ref> frame, followed by zero
+ or more <x:ref>CONTINUATION</x:ref> frames:
+ </t>
+ <figure>
+ <artwork type="inline"><![CDATA[
+ Extension-Field: bar ==> - END_STREAM
+ :status = 103
+ extension-field = bar
+ </figure>
<section anchor="Reliability" title="Request Reliability Mechanisms in HTTP/2">
@@ -4433,21 +4448,6 @@ HTTP2-Settings = token68
<seriesInfo name="RFC" value="1323" />
- <reference anchor="RFC2518">
- <front>
- <title>
- HTTP Extensions for Distributed Authoring -- WEBDAV
- </title>
- <author initials="Y." surname="Goland" fullname="Y. Y. Goland"/>
- <author initials="E." surname="Whitehead" fullname="E. J. Whitehead, Jr."/>
- <author initials="A." surname="Faizi" fullname="A. Faizi"/>
- <author initials="S." surname="Carter" fullname="S. R. Carter"/>
- <author initials="D." surname="Jensen" fullname="D. Jensen"/>
- <date year="1999" month="February" />
- </front>
- <seriesInfo name="RFC" value="2518" />
- </reference>
<reference anchor="RFC3749">
<title>Transport Layer Security Protocol Compression Methods</title>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment