Script updating gh-pages from 7656c73. [ci skip]

define-terms/draft-ietf-quic-http.html

@@ -382,7 +382,7 @@
 
   <meta name="dct.creator" content="Bishop, M., Ed." />
   <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-quic-http-latest" />
-  <meta name="dct.issued" scheme="ISO8601" content="2019-06-27" />
+  <meta name="dct.issued" scheme="ISO8601" content="2019-06-28" />
   <meta name="dct.abstract" content="The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment.  This document describes a mapping of HTTP semantics over QUIC.  This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3." />
   <meta name="description" content="The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment.  This document describes a mapping of HTTP semantics over QUIC.  This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3." />
 
@@ -403,10 +403,10 @@
 </tr>
 <tr>
 <td class="left">Intended status: Standards Track</td>
-<td class="right">June 27, 2019</td>
+<td class="right">June 28, 2019</td>
 </tr>
 <tr>
-<td class="left">Expires: December 29, 2019</td>
+<td class="left">Expires: December 30, 2019</td>
 <td class="right"></td>
 </tr>
 
@@ -426,7 +426,7 @@ <h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
 <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
 <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF).  Note that other groups may also distribute working documents as Internet-Drafts.  The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
 <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.  It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
-<p>This Internet-Draft will expire on December 29, 2019.</p>
+<p>This Internet-Draft will expire on December 30, 2019.</p>
 <h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
 <p>Copyright (c) 2019 IETF Trust and the persons identified as the document authors.  All rights reserved.</p>
 <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document.  Please review these documents carefully, as they describe your rights and restrictions with respect to this document.  Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
@@ -789,7 +789,7 @@ <h2 id="rfc.section.4.1">
 <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 abort reading the receiving part of the request stream with error code HTTP_EARLY_RESPONSE, send a complete response, and cleanly close the sending part of the 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.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 abort reading the request stream with error code HTTP_EARLY_RESPONSE, send a complete response, and cleanly close the sending part of the 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>
@@ -802,9 +802,9 @@ <h3 id="rfc.section.4.1.1">
 <h3 id="rfc.section.4.1.2">
 <a href="#rfc.section.4.1.2">4.1.2.</a> <a href="#request-cancellation" id="request-cancellation">Request Cancellation and Rejection</a>
 </h3>
-<p id="rfc.section.4.1.2.p.1">Clients can cancel requests by abruptly terminating the sending part of the request stream with an error code of HTTP_REQUEST_CANCELLED (<a href="#http-error-codes" class="xref">Section 8.1</a>).  When the client aborts reading a response, it indicates that this response is no longer of interest. Implementations SHOULD cancel requests by terminating both directions of a stream.</p>
+<p id="rfc.section.4.1.2.p.1">Clients can cancel requests by resetting the request stream with an error code of HTTP_REQUEST_CANCELLED (<a href="#http-error-codes" class="xref">Section 8.1</a>).  When the client aborts reading a response, it indicates that this response is no longer of interest.  Implementations SHOULD cancel requests by terminating both directions of a stream.</p>
 <p id="rfc.section.4.1.2.p.2">When the server rejects a request without performing any application processing, it SHOULD abort its response stream with the error code HTTP_REQUEST_REJECTED.  In this context, &#8220;processed&#8221; means that some data from the stream was passed to some higher layer of software that might have taken some action as a result. The client can treat requests rejected by the server as though they had never been sent at all, thereby allowing them to be retried later on a new connection.  Servers MUST NOT use the HTTP_REQUEST_REJECTED error code for requests which were partially or fully processed.  When a server abandons a response after partial processing, it SHOULD abort its response stream with the error code HTTP_REQUEST_CANCELLED.</p>
-<p id="rfc.section.4.1.2.p.3">When a client abruptly terminates a request with the error code HTTP_REQUEST_CANCELLED, a server MAY abruptly terminate the response using the error code HTTP_REQUEST_REJECTED if no processing was performed.  Clients MUST NOT use the HTTP_REQUEST_REJECTED error code, except when a server has requested closure of the request stream with this error code.</p>
+<p id="rfc.section.4.1.2.p.3">When a client resets a request with the error code HTTP_REQUEST_CANCELLED, a server MAY abruptly terminate the response using the error code HTTP_REQUEST_REJECTED if no processing was performed.  Clients MUST NOT use the HTTP_REQUEST_REJECTED error code, except when a server has requested closure of the request stream with this error code.</p>
 <p id="rfc.section.4.1.2.p.4">If a stream is cancelled after receiving a complete response, the client MAY ignore the cancellation and use the response.  However, if a stream is cancelled after receiving a partial response, the response SHOULD NOT be used.  Automatically retrying such requests is not possible, unless this is otherwise permitted (e.g., idempotent actions like GET, PUT, or DELETE).</p>
 <h3 id="rfc.section.4.1.3">
 <a href="#rfc.section.4.1.3">4.1.3.</a> <a href="#malformed" id="malformed">Malformed Requests and Responses</a>
@@ -1373,7 +1373,7 @@ <h1 id="rfc.section.8">
 <h2 id="rfc.section.8.1">
 <a href="#rfc.section.8.1">8.1.</a> <a href="#http-error-codes" id="http-error-codes">HTTP/3 Error Codes</a>
 </h2>
-<p id="rfc.section.8.1.p.1">The following error codes are defined for use when abruptly terminating the sending part of streams, aborting reading of the receiving part of streams, or immediately closing connections.</p>
+<p id="rfc.section.8.1.p.1">The following error codes are defined for use when abruptly terminating streams, aborting reading of streams, or immediately closing connections.</p>
 <p></p>
 
 <dl>