From f3a8cbda7d96ae93042c53b514044b01480d97be Mon Sep 17 00:00:00 2001 From: lucas Date: Tue, 28 Apr 2020 14:47:59 +0100 Subject: [PATCH 1/2] editorial advice for h2<->h3 error propagation --- draft-ietf-quic-http.md | 35 ++++++++++++++++++++++++++++++++--- 1 file changed, 32 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index ae3e9074ca..6d24fe40bd 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -2355,9 +2355,8 @@ the peers' settings to arrive before responding to other streams. See ## HTTP/2 Error Codes QUIC has the same concepts of "stream" and "connection" errors that HTTP/2 -provides. However, there is no direct portability of HTTP/2 error codes to -HTTP/3 error codes; the values are shifted in order to prevent accidental -or implicit conversion. +provides. However, the differences between HTTP/2 and HTTP/3 mean that error +codes are not directly portable between versions. The HTTP/2 error codes defined in Section 7 of {{?HTTP2}} logically map to the HTTP/3 error codes as follows: @@ -2412,6 +2411,36 @@ H3_1_1_REQUIRED (0xd): Error codes need to be defined for HTTP/2 and HTTP/3 separately. See {{iana-error-codes}}. +### Propagating errors between HTTP/2 and HTTP/3 + +An intermediary that converts between HTTP/2 and HTTP/3 is likely to need to +propagate error conditions in either direction. Conversion between errors is +described in the logical mapping. The error codes are defined in non-overlapping +spaces in order to protect against accidental conversion that could result in +the use of inappropriate or unknown error codes for the target version. + +It is not required to convert an inbound error type to the closest matching +outbound error type e.g. converting an HTTP/2 stream error to an HTTP/3 stream +error. An intermediary might instead choose to convert HTTP/2 errors from an +upstream origin into an HTTP response that indicates an error via a status code +such as 502. An example of where this is useful is to convert an upstream server +HTTP/2 error code of INTERNAL_ERROR, thus avoiding an HTTP/3 client believing +there is an internal error in the intermediary. + +There are cases where it is beneficial to provide the closest matching error +type to the receiver. For example, an intermediary that receives an HTTP/2 +stream error of type REFUSED_STREAM from the origin has a clear signal that the +request was not processed and that the request is safe to retry. Propagating +this error condition to the client as an HTTP/3 stream error of type +H3_REQUEST_REJECTED allows the client to take the action it deems most +appropriate. Similarly, it could benefit the origin if the intermediary can pass +on client request cancellations that are indicated by terminating a stream with +H3_REQUEST_CANCELLED. + +An intermediary is permitted to promote stream errors to connection errors but +they should be aware of the cost to the connection for what might be a temporary +or intermittent error. + # Change Log > **RFC Editor's Note:** Please remove this section prior to publication of a From f8cfee09124ce4518b5365a4554c9ce21ed0ecee Mon Sep 17 00:00:00 2001 From: lucas Date: Fri, 1 May 2020 19:53:42 +0100 Subject: [PATCH 2/2] Mike's feedback: invert the advice --- draft-ietf-quic-http.md | 56 ++++++++++++++++++++--------------------- 1 file changed, 27 insertions(+), 29 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 6d24fe40bd..40755ba33b 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -2411,35 +2411,33 @@ H3_1_1_REQUIRED (0xd): Error codes need to be defined for HTTP/2 and HTTP/3 separately. See {{iana-error-codes}}. -### Propagating errors between HTTP/2 and HTTP/3 - -An intermediary that converts between HTTP/2 and HTTP/3 is likely to need to -propagate error conditions in either direction. Conversion between errors is -described in the logical mapping. The error codes are defined in non-overlapping -spaces in order to protect against accidental conversion that could result in -the use of inappropriate or unknown error codes for the target version. - -It is not required to convert an inbound error type to the closest matching -outbound error type e.g. converting an HTTP/2 stream error to an HTTP/3 stream -error. An intermediary might instead choose to convert HTTP/2 errors from an -upstream origin into an HTTP response that indicates an error via a status code -such as 502. An example of where this is useful is to convert an upstream server -HTTP/2 error code of INTERNAL_ERROR, thus avoiding an HTTP/3 client believing -there is an internal error in the intermediary. - -There are cases where it is beneficial to provide the closest matching error -type to the receiver. For example, an intermediary that receives an HTTP/2 -stream error of type REFUSED_STREAM from the origin has a clear signal that the -request was not processed and that the request is safe to retry. Propagating -this error condition to the client as an HTTP/3 stream error of type -H3_REQUEST_REJECTED allows the client to take the action it deems most -appropriate. Similarly, it could benefit the origin if the intermediary can pass -on client request cancellations that are indicated by terminating a stream with -H3_REQUEST_CANCELLED. - -An intermediary is permitted to promote stream errors to connection errors but -they should be aware of the cost to the connection for what might be a temporary -or intermittent error. +### Mapping Between HTTP/2 and HTTP/3 Errors + +An intermediary that converts between HTTP/2 and HTTP/3 may encounter error +conditions from either upstream. It is useful to communicate the occurrence of +error to the downstream but error codes largely reflect connection-local +problems that generally do not make sense to propagate. + +An intermediary that encounters an error from an upstream origin can indicate +this by sending an HTTP status code such as 502, which is suitable for a broad +class of errors. + +There are some rare cases where it is beneficial to propagate the error by +mapping it to the closest matching error type to the receiver. For example, an +intermediary that receives an HTTP/2 stream error of type REFUSED_STREAM from +the origin has a clear signal that the request was not processed and that the +request is safe to retry. Propagating this error condition to the client as an +HTTP/3 stream error of type H3_REQUEST_REJECTED allows the client to take the +action it deems most appropriate. In the reverse direction the intermediary +might deem it beneficial to pass on client request cancellations that are +indicated by terminating a stream with H3_REQUEST_CANCELLED. + +Conversion between errors is described in the logical mapping. The error codes +are defined in non-overlapping spaces in order to protect against accidental +conversion that could result in the use of inappropriate or unknown error codes +for the target version. An intermediary is permitted to promote stream errors to +connection errors but they should be aware of the cost to the connection for +what might be a temporary or intermittent error. # Change Log