Draft: draft-ietf-quic-http

Commentary: This change sounds good to me , but to make sure I understand : is the only purpose of this change to split HTTPREQUESTCANCELLED in two ; client to server stays HTTPREQUESTCANCELLED and server to client now becomes HTTPREQUESTREJECTED ? And is the goal to add clarity when parsing connection logs later ? 
 basically . In the previous text , CANCELLED had specific semantics when sent server - client . However , with the change to make RESETSTREAM reflect back the error code in STOPSENDING , the client - server STOPSENDING(CANCELLED ) would provoke a RESETSTREAM(CANCELLED ) in the server - client direction with that error code that did n't necessarily match those semantics . Hence the split -- one code has specific semantics when sent by a server , and clients are instructed to use the other code . ( I would prohibit clients from sending it , but if the server sends a STOP_SENDING , the client would reflect it back and violate the prohibition , so .... )
Paragraph (version A):
Either client or server can cancel requests by aborting the stream
(QUIC RESET_STREAM and/or STOP_SENDING frames, as appropriate) with
an error code of HTTP_REQUEST_CANCELLED (http-error-codes).  When the
client cancels a response, it indicates that this response is no
longer of interest.  Implementations SHOULD cancel requests by
aborting both directions of a stream.
Paragraph (version A):
When the server aborts its response stream using
HTTP_REQUEST_CANCELLED, it indicates that no application processing
was performed.  In this context, "processed" 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 cancelled 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_CANCELLED status
for requests which were partially or fully processed.
Paragraph (version B):
Clients can cancel requests by aborting the stream (QUIC RESET_STREAM
and/or STOP_SENDING frames, as appropriate) with an error code of
HTTP_REQUEST_CANCELLED (http-error-codes).  When the client cancels a
response, it indicates that this response is no longer of interest.
Implementations SHOULD cancel requests by aborting both directions of
a stream.
Paragraph (version B):
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, "processed" 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 client
sends a STOP_SENDING with HTTP_REQUEST_CANCELLED, a server MAY
indicate the error code HTTP_REQUEST_REJECTED in the corresponding
RESET_STREAM if no processing was performed.  Clients MUST NOT reset
streams with the HTTP_REQUEST_REJECTED error code except in response
to a QUIC STOP_SENDING frame.
Paragraph (version A):
Servers initiate the shutdown of a connection by sending a GOAWAY
frame (frame-goaway).  The GOAWAY frame indicates that client-
initiated requests on lower stream IDs were or might be processed in
this connection, while requests on the indicated stream ID and
greater were not accepted.  This enables client and server to agree
on which requests were accepted prior to the connection shutdown.
This identifier MAY be lower than the stream limit identified by a
QUIC MAX_STREAM_ID frame, and MAY be zero if no requests were
processed.  Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit
after sending a GOAWAY frame.
Paragraph (version A):
Once GOAWAY is sent, the server MUST cancel requests sent on streams
with an identifier higher than the indicated last Stream ID.  Clients
MUST NOT send new requests on the connection after receiving GOAWAY,
although requests might already be in transit.  A new connection can
be established for new requests.
Paragraph (version A):
If the client has sent requests on streams with a higher Stream ID
than indicated in the GOAWAY frame, those requests are considered
cancelled (request-cancellation).  Clients SHOULD reset any streams
above this ID with the error code HTTP_REQUEST_CANCELLED.  Servers
MAY also cancel requests on streams below the indicated ID if these
requests were not processed.
Paragraph (version B):
Servers initiate the shutdown of a connection by sending a GOAWAY
frame (frame-goaway).  The GOAWAY frame indicates that client-
initiated requests on lower stream IDs were or might be processed in
this connection, while requests on the indicated stream ID and
greater were rejected.  This enables client and server to agree on
which requests were accepted prior to the connection shutdown.  This
identifier MAY be lower than the stream limit identified by a QUIC
MAX_STREAM_ID frame, and MAY be zero if no requests were processed.
Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after
sending a GOAWAY frame.
Paragraph (version B):
Once GOAWAY is sent, the server MUST reject requests sent on streams
with an identifier greater than or equal to the indicated last Stream
ID.  Clients MUST NOT send new requests on the connection after
receiving GOAWAY, although requests might already be in transit.  A
new connection can be established for new requests.
Paragraph (version B):
If the client has sent requests on streams with a Stream ID greater
than or equal to that indicated in the GOAWAY frame, those requests
are considered rejected (request-cancellation).  Clients SHOULD
cancel any requests on streams above this ID.  Servers MAY also
reject requests on streams below the indicated ID if these requests
were not processed.
Paragraph (version A):
Servers SHOULD send a GOAWAY frame when the closing of a connection
is known in advance, even if the advance notice is small, so that the
remote peer can know whether a stream has been partially processed or
not.  For example, if an HTTP client sends a POST at the same time
that a server closes a QUIC connection, the client cannot know if the
server started to process that POST request if the server does not
send a GOAWAY frame to indicate what streams it might have acted on.
Paragraph (version B):
Servers SHOULD send a GOAWAY frame when the closing of a connection
is known in advance, even if the advance notice is small, so that the
remote peer can know whether a request has been partially processed
or not.  For example, if an HTTP client sends a POST at the same time
that a server closes a QUIC connection, the client cannot know if the
server started to process that POST request if the server does not
send a GOAWAY frame to indicate what streams it might have acted on.
Paragraph (version B):
A server rejected a request without performing any application
processing.