Script updating gh-pages from cdd2c25. [ci skip]

DaanDeMeyer-specify-data-before-headers-error/draft-ietf-quic-http.html

@@ -769,11 +769,12 @@ <h2 id="rfc.section.4.1">
 <p id="rfc.section.4.1.p.4">A server MAY interleave one or more PUSH_PROMISE frames (see <a href="#frame-push-promise" class="xref">Section 7.2.6</a>) with the frames of a response message. These PUSH_PROMISE frames are not part of the response; see <a href="#server-push" class="xref">Section 4.4</a> for more details.</p>
 <p id="rfc.section.4.1.p.5">The HEADERS and PUSH_PROMISE frames might reference updates to the QPACK dynamic table. While these updates are not directly part of the message exchange, they must be received and processed before the message can be consumed.  See <a href="#header-formatting" class="xref">Section 4.1.1</a> for more details.</p>
 <p id="rfc.section.4.1.p.6">The &#8220;chunked&#8221; transfer encoding defined in Section 4.1 of <a href="#RFC7230" class="xref">[RFC7230]</a> MUST NOT be used.</p>
-<p id="rfc.section.4.1.p.7">Trailing header fields are carried in an additional HEADERS frame following the body. Senders MUST send only one HEADERS frame in the trailers section; receivers MUST discard any subsequent HEADERS frames.</p>
-<p id="rfc.section.4.1.p.8">A response MAY consist of multiple messages when and only when one or more informational responses (1xx; see <a href="#RFC7231" class="xref">[RFC7231]</a>, Section 6.2) precede a final response to the same request.  Non-final responses do not contain a payload body or trailers.</p>
-<p id="rfc.section.4.1.p.9">An HTTP request/response exchange fully consumes a bidirectional QUIC stream.  After sending a request, a client MUST close the stream for sending.  Unless using the CONNECT method (see <a href="#the-connect-method" class="xref">Section 4.2</a>), clients MUST NOT make stream closure dependent on receiving a response to their request. After sending a final response, the server MUST close the stream for sending. At this point, the QUIC stream is fully closed.</p>
-<p id="rfc.section.4.1.p.10">When a stream is closed, this indicates the end of an HTTP message. Because some messages are large or unbounded, endpoints SHOULD begin processing partial HTTP messages once enough of the message has been received to make progress.  If a client stream terminates without enough of the HTTP message to provide a complete response, the server SHOULD abort its response with the error code HTTP_INCOMPLETE_REQUEST.</p>
-<p id="rfc.section.4.1.p.11">A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received. When this is true, a server MAY request that the client abort transmission of a request without error by triggering a QUIC STOP_SENDING frame with error code HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing its stream. Clients MUST NOT discard complete responses as a result of having their request terminated abruptly, though clients can always discard responses at their discretion for other reasons.</p>
+<p id="rfc.section.4.1.p.7">If a DATA frame is received before a HEADERS frame on a request stream, the recipient must respond with a connection error (<a href="#errors" class="xref">Section 8</a>) of type HTTP_UNEXPECTED_FRAME.</p>
+<p id="rfc.section.4.1.p.8">Trailing header fields are carried in an additional HEADERS frame following the body. Senders MUST send only one HEADERS frame in the trailers section; receivers MUST discard any subsequent HEADERS frames.</p>
+<p id="rfc.section.4.1.p.9">A response MAY consist of multiple messages when and only when one or more informational responses (1xx; see <a href="#RFC7231" class="xref">[RFC7231]</a>, Section 6.2) precede a final response to the same request.  Non-final responses do not contain a payload body or trailers.</p>
+<p id="rfc.section.4.1.p.10">An HTTP request/response exchange fully consumes a bidirectional QUIC stream.  After sending a request, a client MUST close the stream for sending.  Unless using the CONNECT method (see <a href="#the-connect-method" class="xref">Section 4.2</a>), clients MUST NOT make stream closure dependent on receiving a response to their request. After sending a final response, the server MUST close the stream for sending. At this point, the QUIC stream is fully closed.</p>
+<p id="rfc.section.4.1.p.11">When a stream is closed, this indicates the end of an HTTP message. Because some messages are large or unbounded, endpoints SHOULD begin processing partial HTTP messages once enough of the message has been received to make progress.  If a client stream terminates without enough of the HTTP message to provide a complete response, the server SHOULD abort its response with the error code HTTP_INCOMPLETE_REQUEST.</p>
+<p id="rfc.section.4.1.p.12">A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received. When this is true, a server MAY request that the client abort transmission of a request without error by triggering a QUIC STOP_SENDING frame with error code HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing its stream. Clients MUST NOT discard complete responses as a result of having their request terminated abruptly, though clients can always discard responses at their discretion for other reasons.</p>
 <h3 id="rfc.section.4.1.1">
 <a href="#rfc.section.4.1.1">4.1.1.</a> <a href="#header-formatting" id="header-formatting">Header Formatting and Compression</a>
 </h3>
@@ -1070,7 +1071,6 @@ <h3 id="rfc.section.7.2.1">
 </h3>
 <p id="rfc.section.7.2.1.p.1">DATA frames (type=0x0) convey arbitrary, variable-length sequences of bytes associated with an HTTP request or response payload.</p>
 <p id="rfc.section.7.2.1.p.2">DATA frames MUST be associated with an HTTP request or response.  If a DATA frame is received on either control stream, the recipient MUST respond with a connection error (<a href="#errors" class="xref">Section 8</a>) of type HTTP_WRONG_STREAM.</p>
-<p id="rfc.section.7.2.1.p.3">If a DATA frame is received before a HEADERS frame on a request stream, the recipient must respond with a connection error (<a href="#errors" class="xref">Section 8</a>) of type HTTP_UNEXPECTED_FRAME.</p>
 <div id="rfc.figure.5"></div>
 <div id="fig-data"></div>
 <pre>