Subject: Analysing the HTTP/3 error code space

From: Lucas Pardue <[email-masked]>
Date: Tue, 11 Jun 2019 18:21:33 +0100

Hello Working Group,

In the London Interim I volunteered to do an analysis of the HTTP/3
error code space. The results shouldn't come as a surprise to many of
us but it helps to summarise things in a single place. The most
controversial aspect is whether there are too many, too specific error
codes. This has come up a few times and now seems as good a time as
any to try for consensus. I've offered some suggestions at the end but
please do share your opinion.

HTTP/3  error codes are based on HTTP/2 error codes. However, because
some of HTTP/2s features are subsumed into QUIC, some of the errors
are no longer required. Conversely, differences in HTTP/3 mean that
new classes of error can arise. For example, HTTP/3 unidirectional
stream types add flexibility but invalidate assumptions about mapping
between stream ID and usage. This requires extra checks to detect if
multiple control streams are created.

The carriage of error codes has also changed. In HTTP/2, error codes
are carried in RST_STREAM and GOAWAY frames. In HTTP/3, application
error codes are carried in QUIC frames: STOP_SENDING, RESET_STREAM and
CONNECTION CLOSE (with type 0x1d). Both protocols have errors that
relate to streams or the connection as a whole, and stream errors may
be upgraded to connection errors.

HTTP/2 and HPACK define a total of 13 error codes. 4 of these are not
applicable in HTTP/3, yet we presently (draft 20) have a total of 24
error codes across HTTP/3 and QPACK. The list below shoes each error
code along with  a count that represents number of occurrences of
guidance text above or beyond the definition

HTTP_NO_ERROR, 1
HTTP_WRONG_SETTING_DIRECTION, 1
HTTP_PUSH_REFUSED, 1
HTTP_INTERNAL_ERROR, 0
HTTP_PUSH_ALREADY_IN_CACHE, 1
HTTP_REQUEST_CANCELLED, 3
HTTP_INCOMPLETE_REQUEST, 4
HTTP_CONNECT_ERROR, 1
HTTP_EXCESSIVE_LOAD, 1
HTTP_VERSION_FALLBACK. 0
HTTP_WRONG_STREAM, 8
HTTP_LIMIT_EXCEEDED, 2
HTTP_DUPLICATE_PUSH, 1
HTTP_UNKNOWN_STREAM_TYPE, 1
HTTP_WRONG_STREAM_COUNT, 2
HTTP_CLOSED_CRITICAL_STREAM, 2
HTTP_WRONG_STREAM_DIRECTION, 1
HTTP_EARLY_RESPONSE, 1
HTTP_MISSING_SETTINGS, 1
HTTP_UNEXPECTED_FRAME, 8
HTTP_REQUEST_REJECTED, 4
HTTP_GENERAL_PROTOCOL_ERROR, 0
HTTP_MALFORMED_FRAME, 9
HTTP_QPACK_DECOMPRESSION_FAILED, 6
HTTP_QPACK_ENCODER_STREAM_ERROR, 4
HTTP_QPACK_DECODER_STREAM_ERROR, 3

Of the total 24 error frames, 14 are only send in the case of a
connection error. The remainder are sent as stream errors, which could
be upgraded to connection errors.

One notable difference is that HTTP/2s FRAME_SIZE_ERROR code has been
replaced by HTTP_MALFORMED_FRAME, which actually covers a range of
values - it dedicates a byte to encode the frame type. This is
problematic since the frame type changed to be a 62-bit integer
itself.  In my personal opinion, this error code is more complicated
than needs be and was incorrectly applied. Issue #2551 [1] captures
this, and PR #2662 [2] contains a proposed set of replacement codes.
That PR adds 4 error codes to bring the total up to 28.

Some observations and suggestions:

0) Appendix A.4 contains a convenient comparison of HTTP/2 and HTTP/3
error codes. However, it states that HTTP/2's PROTOCOL_ERROR has no
single equivalent, which I think is incorrect becuase HTTP/3 has
HTTP_GENERAL_PROTOCOL_ERROR.
1) HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME are used a lot and very
similar. The former is used by a peer that receives a valid frame on a
stream that it should never be sent on, the latter is used by a peer
that receives a valid frame on a stream that is normally ok but has
transitioned to an application-level stream state which prohibits it.
Rationalising these seems like a logical option.
2) HTTP_WRONG_SETTING_DIRECTION presently applies to exactly one case,
a client send NUM_PLACEHOLDER. Declassifying this as an error seems
like a sensile option. This frees up error code 0x1, which we can move
HTTP_GENERAL_PROTOCOL_ERROR to (making HTTP/3 more similar to HTTP/2).
3) HTTP_PUSH_REFUSED and HTTP_PUSH_ALREADY_IN_CACHE are very similar
but may be useful to understand the different reason that clients
reject server push. This is extra fidelity on top of HTTP/2.
4) There are several error codes related to handling requests and
responses: HTTP_REQUEST_CANCELLED, HTTP_INCOMPLETE_REQUEST,
HTTP_EARLY_RESPONSE, HTTP_REQUEST_REJECTED, . This is extra fidelity
than HTTP/2 provided. This may extra information may allow endpoints
to make smarter decisions about retrying requests. However, it may
also be possible to infer things from a stream error that contains
simply HTTP_NO_ERROR ( HTTP_EARLY_RESPONSE could benefit from this)
5) The error code guidance is often not symmetric. Client or servers
use error codes differently and little guidance is provided on how to
process an error code that in theory should never be sent.
6) There is little guidance on how an intermediary that translates
between HTTP/2 and HTTP/3 should map these divergent error code
spaces. It would pay to align them as close as possible and provide
some guidance on how to map higher fidelity codes to lower fidelity
codes.
7) There are several error cases related to SETTINGS; a frame that can
be sent most once per connection. I made a proposal to address this on
issue #2783 [3]
8) HTTP_UNKNOWN_STREAM_TYPE and DUPLICATE_PUSH both relate to parsing
the unidirectional stream type header. We might be able to merge these
into a error such as HTTP_STREAM_HEADER_ERROR and state the code has
different applicability between STOP_SENDING and CONNECTION_CLOSE
frames.
9) Critical streams such as control stream and QPACK streams can be
created only once; HTTP_WRONG_STREAM_COUNT captures this. Push streams
can only be created by a server and HTTP_WRONG_STREAM_DIRECTION
captures this. We could rationalise these into
HTTP_STREAM_CREATION_ERROR, that could even incorporate suggestion 8.
10) There are 3 QPACK errors in contrast to 1 HPACK error. I think
this is fair given the new complexity and scope for implementations to
make errors.

Cheers,
Lucas

[1] - https://github.com/quicwg/base-drafts/issues/2551
[2] - https://github.com/quicwg/base-drafts/pull/2662
[3] - https://github.com/quicwg/base-drafts/issues/2783

---

From: Ian Swett <[email-masked]>
Date: Tue, 11 Jun 2019 14:13:47 -0400

Thanks for the awesome work, a few comments below, but I think I'm happy
with your suggested changes.

> That PR adds 4 error codes to bring the total up to 28.

I like your proposed PR.

> this is fair given the new complexity and scope for implementations to

Any thoughts on HTTP_VERSION_FALLBACK and HTTP_INTERNAL_ERROR, which are
never used?  I'm unclear on what the intended usage is?

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 11 Jun 2019 19:53:13 +0100

Hey Ian,

>> That PR adds 4 error codes to bring the total up to 28.

Thanks. The TL;DR of the PR is that it add back FRAME_SIZE_ERROR (for
things that are frame size errors) and adds some new error codes in
agreement with our current philosophy. I would refine the PR to agree
with the outcome of this thread.

>
> Any thoughts on HTTP_VERSION_FALLBACK and HTTP_INTERNAL_ERROR, which are never used?  I'm unclear on what the intended usage is?

I realised I didn't qualify one aspect of my analysis - the guidance
count metric is only one signal. HTTP_INTERNAL_ERROR is described as
"An internal error has occurred in the HTTP stack.", which feels like
an implementation-oriented error code. I think it is valid in staying
in HTTP/3, especially if it is used in HTTP/2 (I don't have data to
hand on that though). However, HTTP_VERSION_FALLBACK is a bit weird;
it stems from HTTP/2's HTTP_1_1_REQUIRED code, which in RFC 7540 is
only recommended when the server wants to use TLS renegotiation. IMO
it is of limited value unless we import the same behaviour into
HTTP/3.

---

From: Martin Duke <[email-masked]>
Date: Tue, 11 Jun 2019 12:36:34 -0700

I would insist on INTERNAL_ERROR. It is great for various malloc problems,
as well as for signalling that something went wrong on the back end in
proxy scenarios. It is a catch-all for "I screwed up and can't continue".

---

From: Mike Bishop <[email-masked]>
Date: Tue, 11 Jun 2019 21:40:45 +0000

I was previously affiliated with an HTTP stack that I assume still needs HTTP_VERSION_FALLBACK for some corner cases including, but not limited to, renegotiation.  This WG previously had a discussion about whether it should fall back to HTTP/2 (logical, but likely has all the same incompatible scenarios that HTTP/3 does) or HTTP/1.1, and concluded that it would be sad to make someone fall from 3 -> 2 -> 1.1 when probably can’t answer over anything higher than 1.1 anyway.

> 0) Appendix A.4 contains a convenient comparison of HTTP/2 and HTTP/3 error codes. However, it states that HTTP/2's PROTOCOL_ERROR has no single equivalent, which I think is incorrect becuase HTTP/3 has HTTP_GENERAL_PROTOCOL_ERROR.

Mostly because the various MALFORMED_FRAME errors would also have been PROTOCOL_ERROR in HTTP/2.  We could make the text point to GPE, while noting that specific error codes have been added for certain situations.

> 1) HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME are used a lot and very similar. The former is used by a peer that receives a valid frame on a stream that it should never be sent on, the latter is used by a peer that receives a valid frame on a stream that is normally ok but has transitioned to an application-level stream state which prohibits it.

> Rationalising these seems like a logical option.

Seems reasonable.  I believe there was previous discussion about possibly combining them, but I can’t find it with a cursory search.

> 2) HTTP_WRONG_SETTING_DIRECTION presently applies to exactly one case, a client send NUM_PLACEHOLDER. Declassifying this as an error seems like a sensile option. This frees up error code 0x1, which we can move HTTP_GENERAL_PROTOCOL_ERROR to (making HTTP/3 more similar to HTTP/2).

> 7) There are several error cases related to SETTINGS; a frame that can be sent most once per connection. I made a proposal to address this on issue #2783 [3]

I need to think more about the proposal in #2783, but that’s semi-orthogonal to the error conversation.  I like the suggestion from the interim to consolidate these to a more general INVALID_SETTINGS error, though if we go the route of #2783, that might become a STREAM_HEADER_ERROR à la (8).

> 3) HTTP_PUSH_REFUSED and HTTP_PUSH_ALREADY_IN_CACHE are very similar but may be useful to understand the different reason that clients reject server push. This is extra fidelity on top of HTTP/2.

> 4) There are several error codes related to handling requests and

responses: HTTP_REQUEST_CANCELLED, HTTP_INCOMPLETE_REQUEST, HTTP_EARLY_RESPONSE, HTTP_REQUEST_REJECTED, . This is extra fidelity than HTTP/2 provided. This may extra information may allow endpoints to make smarter decisions about retrying requests. However, it may also be possible to infer things from a stream error that contains simply HTTP_NO_ERROR ( HTTP_EARLY_RESPONSE could benefit from this)

We need the CANCELLED/REJECTED split to understand when a server is declaring that no processing occurred versus reflecting back the error code from the client’s STOP_SENDING in a RESET_STREAM.  (The resolution to that is that clients don’t send REJECTED, and it has the additional semantic when coming from a server.)  If we didn’t have INCOMPLETE_REQUEST, I’m unsure what we’d send in that situation instead; it’s certainly not a NO_ERROR situation.

Folding EARLY_RESPONSE into NO_ERROR would be reasonable.

> 5) The error code guidance is often not symmetric. Client or servers use error codes differently and little guidance is provided on how to process an error code that in theory should never be sent.

The only possible response is blowing up the connection, isn’t it?  Which is superfluous if you’ve received a nonsensical connection error, because the connection is already being blown up by the peer.  So the more scoped question is, if a stream sees a RESET/STOP_SENDING with an error code that a) should only have originated from your side, or b) can only be a connection error, what do you do?

> 6) There is little guidance on how an intermediary that translates between HTTP/2 and HTTP/3 should map these divergent error code spaces. It would pay to align them as close as possible and provide some guidance on how to map higher fidelity codes to lower fidelity codes.

That’s a good point.  However, error codes are hop-to-hop – I suspect that any error code gets turned into a status code 502, with the possible exception of REJECTED.  Do expect anyone to build a 2/3 intermediary who isn’t also terminating the HTTP semantic layer?

> 8) HTTP_UNKNOWN_STREAM_TYPE and DUPLICATE_PUSH both relate to parsing the unidirectional stream type header. We might be able to merge these into a error such as HTTP_STREAM_HEADER_ERROR and state the code has different applicability between STOP_SENDING and CONNECTION_CLOSE frames.

> 9) Critical streams such as control stream and QPACK streams can be created only once; HTTP_WRONG_STREAM_COUNT captures this. Push streams can only be created by a server and HTTP_WRONG_STREAM_DIRECTION captures this. We could rationalise these into HTTP_STREAM_CREATION_ERROR, that could even incorporate suggestion 8.

DUPLICATE_PUSH can also refer to a second PUSH_PROMISE with the same Push ID.  Otherwise, a STREAM_HEADER_ERROR or STREAM_CREATION_ERROR seems like a reasonable collation; I agree that those are ultimately the same proposal.

From: QUIC <[email-masked]> On Behalf Of Martin Duke
Sent: Tuesday, June 11, 2019 12:37 PM
To: Lucas Pardue <[email-masked]>
Cc: Ian Swett <[email-masked]>; QUIC WG <[email-masked]>
Subject: Re: Analysing the HTTP/3 error code space

I would insist on INTERNAL_ERROR. It is great for various malloc problems, as well as for signalling that something went wrong on the back end in proxy scenarios. It is a catch-all for "I screwed up and can't continue".

On Tue, Jun 11, 2019 at 11:53 AM Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:
 Hey Ian,

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 12 Jun 2019 11:43:34 +0900

> That’s a good point.  However, error codes are hop-to-hop – I suspect that any error code gets turned into a status code 502, with the possible exception of REJECTED.  Do expect anyone to build a 2…

Not that we do now as a proxy implementation, but I think it would be
preferable to propagate "temporary" errors (REFUSED_STREAM), and also
CONNECT_ERROR to indicate reset of a websocket connection. For all
other errors I think that 502 can be used.

It might be worth clarifying that such behavior is to be expected (or
preferable).

> On Tue, Jun 11, 2019 at 11:53 AM Lucas Pardue <[email-masked]> wrote:
>
>  Hey Ian,
>

-- 
Kazuho Oku

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 15 Jun 2019 13:43:55 +0100

Thank you all for the input.

Seeing some support, with valuable suggestions, I will start on a series of
issues/PRs to let us refine the specifics.

On Wed, 12 Jun 2019, 03:43 Kazuho Oku, <[email-masked]> wrote:

> > I was previously affiliated with an HTTP stack that I assume still needs
> HTTP_VERSION_FALLBACK for some corner cases including, but not limited to,
> renegotiation.  This WG previously had a discussion about whether it should
> fall back to HTTP/2 (logical, but likely has all the same incompatible
> scenarios that HTTP/3 does) or HTTP/1.1, and concluded that it would be sad
> to make someone fall from 3 -> 2 -> 1.1 when probably can’t answer over
> anything higher than 1.1 anyway.
> >
> >
> >
> error codes. However, it states that HTTP/2's PROTOCOL_ERROR has no single
> equivalent, which I think is incorrect becuase HTTP/3 has
> > Mostly because the various MALFORMED_FRAME errors would also have been
> PROTOCOL_ERROR in HTTP/2.  We could make the text point to GPE, while
> noting that specific error codes have been added for certain situations.
> >
> >
> >
> stream that it should never be sent on, the latter is used by a peer that
> receives a valid frame on a stream that is normally ok but has transitioned
> to an application-level stream state which prohibits it.
> >
> > Seems reasonable.  I believe there was previous discussion about
> possibly combining them, but I can’t find it with a cursory search.
> >
> >
> >
> a client send NUM_PLACEHOLDER. Declassifying this as an error seems like a
> sensile option. This frees up error code 0x1, which we can move
> > I need to think more about the proposal in #2783, but that’s
> semi-orthogonal to the error conversation.  I like the suggestion from the
> interim to consolidate these to a more general INVALID_SETTINGS error,
> though if we go the route of #2783, that might become a STREAM_HEADER_ERROR
> à la (8).
> >
> >
> >
> but may be useful to understand the different reason that clients reject
> server push. This is extra fidelity on top of HTTP/2.
> >
> HTTP_EARLY_RESPONSE, HTTP_REQUEST_REJECTED, . This is extra fidelity than
> HTTP/2 provided. This may extra information may allow endpoints to make
> smarter decisions about retrying requests. However, it may also be possible
> to infer things from a stream error that contains simply HTTP_NO_ERROR (
> HTTP_EARLY_RESPONSE could benefit from this)
> >
> >
> >
> > We need the CANCELLED/REJECTED split to understand when a server is
> declaring that no processing occurred versus reflecting back the error code
> from the client’s STOP_SENDING in a RESET_STREAM.  (The resolution to that
> is that clients don’t send REJECTED, and it has the additional semantic
> when coming from a server.)  If we didn’t have INCOMPLETE_REQUEST, I’m
> unsure what we’d send in that situation instead; it’s certainly not a
> NO_ERROR situation.
> >
> >
> >
> > The only possible response is blowing up the connection, isn’t it?
> Which is superfluous if you’ve received a nonsensical connection error,
> because the connection is already being blown up by the peer.  So the more
> scoped question is, if a stream sees a RESET/STOP_SENDING with an error
> code that a) should only have originated from your side, or b) can only be
> a connection error, what do you do?
> >
> >
> >
> between HTTP/2 and HTTP/3 should map these divergent error code spaces. It
> would pay to align them as close as possible and provide some guidance on
> how to map higher fidelity codes to lower fidelity codes.
> >
> >
> >
> > That’s a good point.  However, error codes are hop-to-hop – I suspect
> that any error code gets turned into a status code 502, with the possible
> exception of REJECTED.  Do expect anyone to build a 2/3 intermediary who
> isn’t also terminating the HTTP semantic layer?
>
> the unidirectional stream type header. We might be able to merge these into
> a error such as HTTP_STREAM_HEADER_ERROR and state the code has different
> applicability between STOP_SENDING and CONNECTION_CLOSE frames.
> >
> created only once; HTTP_WRONG_STREAM_COUNT captures this. Push streams can
> only be created by a server and HTTP_WRONG_STREAM_DIRECTION captures this.
> We could rationalise these into HTTP_STREAM_CREATION_ERROR, that could even
> incorporate suggestion 8.
> >
> >
> >
> > DUPLICATE_PUSH can also refer to a second PUSH_PROMISE with the same
> Push ID.  Otherwise, a STREAM_HEADER_ERROR or STREAM_CREATION_ERROR seems
> like a reasonable collation; I agree that those are ultimately the same
> proposal.
> >
> >
> >
> >
> >
> > I would insist on INTERNAL_ERROR. It is great for various malloc
> problems, as well as for signalling that something went wrong on the back
> end in proxy scenarios. It is a catch-all for "I screwed up and can't
> continue".
> >
> >
> >
> > > Any thoughts on HTTP_VERSION_FALLBACK and HTTP_INTERNAL_ERROR, which
> are never used?  I'm unclear on what the intended usage is?
> >

---

From: Mike Bishop <[email-masked]>
Date: Tue, 25 Jun 2019 23:29:18 +0000

For those not following GitHub closely, I’d like to point out that these proposals have shown up as PRs, and that they have been reviewed by a few of us over there.  I plan to merge later this week, modulo any objections.

  *   #2808<https://github.com/quicwg/base-drafts/pull/2808> makes the H2 comparison point from PROTOCOL_ERROR to GENERAL_PROTOCOL_ERROR, while noting that H3 has more specific error codes for some things that were PE in H2
  *   #2813<https://github.com/quicwg/base-drafts/pull/2813>:  Expands the use of REQUEST_CANCELLED to cancelling push streams and removes the more specific error codes for why one might not want the pushed content
  *   #2814<https://github.com/quicwg/base-drafts/pull/2814>:  Collects anything that could be wrong with the payload of a SETTINGS frame (server settings sent by clients, duplicates) into SETTINGS_ERROR
  *   #2820<https://github.com/quicwg/base-drafts/pull/2820>:  Groups LIMIT_EXCEEDED and various misuses of Push IDs into a single error code (ID_ERROR) for any misuse of identifiers defined by HTTP
  *   #2822<https://github.com/quicwg/base-drafts/pull/2822>:  Groups UNKNOWN_STREAM_TYPE, WRONG_STREAM_COUNT, and WRONG_STREAM_DIRECTION into a single error code (STREAM_CREATION_ERROR) for any reason why a newly opened unidirectional stream is unacceptable to the recipient

If you have feedback on these, please speak now, either here or on GitHub.

Once these are in, #2662<https://github.com/quicwg/base-drafts/pull/2662> probably needs to be reworked slightly and should land soon as well.  Lucas has been leaving the no-longer-used error codes as Reserved in each of these PRs; after they land, he or I will do another PR to condense the error code space.

From: Lucas Pardue <[email-masked]>
Sent: Saturday, June 15, 2019 5:44 AM
To: Kazuho Oku <[email-masked]>
Cc: Mike Bishop <[email-masked]>; Martin Duke <[email-masked]>; Ian Swett <[email-masked]>; QUIC WG <[email-masked]>
Subject: Re: Analysing the HTTP/3 error code space

Seeing some support, with valuable suggestions, I will start on a series of issues/PRs to let us refine the specifics.

On Wed, 12 Jun 2019, 03:43 Kazuho Oku, <[email-masked]<mailto:[email-masked]>> wrote:

> From: QUIC <[email-masked]<mailto:[email-masked]>> On Behalf Of Martin Duke
> To: Lucas Pardue <[email-masked]<mailto:[email-masked]>>
> Cc: Ian Swett <[email-masked]<mailto:[email-masked]>>; QUIC WG <[email-masked]<mailto:[email-masked]>>

--
Kazuho Oku

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 26 Jun 2019 00:44:42 +0100

Hey Mike,

Thanks for putting that list together. I was thinking something like this
would be useful to echo back to the thread, you kindly saved me the effort.

My approach h was the keep issues as independent as possible, so we can
continue to make progress even some turned out contentious. My plan was to
do another pass once a few get merged and aim to consolidate everything
down - error code rightsizing so to speak.

Lucas

On Wed, 26 Jun 2019, 00:29 Mike Bishop, <[email-masked]> wrote:

> For those not following GitHub closely, I’d like to point out that these
> proposals have shown up as PRs, and that they have been reviewed by a few
> of us over there.  I plan to merge later this week, modulo any objections.
>
>    - #2808 <https://github.com/quicwg/base-drafts/pull/2808> makes the H2
>    comparison point from PROTOCOL_ERROR to GENERAL_PROTOCOL_ERROR, while
>    noting that H3 has more specific error codes for some things that were PE
>    in H2
>    - #2813 <https://github.com/quicwg/base-drafts/pull/2813>:  Expands
>    the use of REQUEST_CANCELLED to cancelling push streams and removes the
>    more specific error codes for why one might not want the pushed content
>    - #2814 <https://github.com/quicwg/base-drafts/pull/2814>:  Collects
>    anything that could be wrong with the payload of a SETTINGS frame (server
>    settings sent by clients, duplicates) into SETTINGS_ERROR
>    - #2820 <https://github.com/quicwg/base-drafts/pull/2820>:  Groups
>    LIMIT_EXCEEDED and various misuses of Push IDs into a single error code
>    (ID_ERROR) for any misuse of identifiers defined by HTTP
>    - #2822 <https://github.com/quicwg/base-drafts/pull/2822>:  Groups
>    UNKNOWN_STREAM_TYPE, WRONG_STREAM_COUNT, and WRONG_STREAM_DIRECTION into a
>    single error code (STREAM_CREATION_ERROR) for any reason why a newly opened
>    unidirectional stream is unacceptable to the recipient
>
>
>
> Once these are in, #2662 <https://github.com/quicwg/base-drafts/pull/2662>
> probably needs to be reworked slightly and should land soon as well.  Lucas
> has been leaving the no-longer-used error codes as Reserved in each of
> these PRs; after they land, he or I will do another PR to condense the
> error code space.
>
>
>
> *From:* Lucas Pardue <[email-masked]>
> *Sent:* Saturday, June 15, 2019 5:44 AM
> *To:* Kazuho Oku <[email-masked]>
> *Cc:* Mike Bishop <[email-masked]>; Martin Duke <
> [email-masked]>; Ian Swett <[email-masked]>; QUIC WG <
> [email-masked]>
> *Subject:* Re: Analysing the HTTP/3 error code space
>
>
>
> Seeing some support, with valuable suggestions, I will start on a series
> of issues/PRs to let us refine the specifics.
>
>
>
>
>
>
>