Subject: Re: [quicwg/base-drafts] Core protocol doc missing RST_STREAM frame error codes (#19)

From: Lucas Pardue <[email-masked]>
Date: Mon, 16 Jan 2017 07:41:56 -0800

The [error code section|https://tools.ietf.org/html/draft-ietf-quic-transport-01#section-11] in draft-ietf-quic-transport-01 has been updated but I still don't think my original issue has been addressed. There is a sentence that says:

> This section lists the defined QUIC transport error codes that may be  used in a CONNECTION_CLOSE or RST_STREAM frame.

However, this is inaccurate as there are ~ 16 stream RST_STREAM error codes missing (see below)

Google's QUIC reset stream error code definition (in code) have moved to  https://chromium.googlesource.com/chromium/src/+/master/net/quic/core/quic_error_codes.h

How would the following error codes map into the new I-D error code space? If you can provide a hint I would be happy to write a PR that put RST_STREAM errors into the doc.

```
enum QuicRstStreamErrorCode {
  // Complete response has been sent, sending a RST to ask the other endpoint
  // to stop sending request data without discarding the response.
  QUIC_STREAM_NO_ERROR = 0,
  // There was some error which halted stream processing.
  QUIC_ERROR_PROCESSING_STREAM,
  // We got two fin or reset offsets which did not match.
  QUIC_MULTIPLE_TERMINATION_OFFSETS,
  // We got bad payload and can not respond to it at the protocol level.
  QUIC_BAD_APPLICATION_PAYLOAD,
  // Stream closed due to connection error. No reset frame is sent when this
  // happens.
  QUIC_STREAM_CONNECTION_ERROR,
  // GoAway frame sent. No more stream can be created.
  QUIC_STREAM_PEER_GOING_AWAY,
  // The stream has been cancelled.
  QUIC_STREAM_CANCELLED,
  // Closing stream locally, sending a RST to allow for proper flow control
  // accounting. Sent in response to a RST from the peer.
  QUIC_RST_ACKNOWLEDGEMENT,
  // Receiver refused to create the stream (because its limit on open streams
  // has been reached).  The sender should retry the request later (using
  // another stream).
  QUIC_REFUSED_STREAM,
  // Invalid URL in PUSH_PROMISE request header.
  QUIC_INVALID_PROMISE_URL,
  // Server is not authoritative for this URL.
  QUIC_UNAUTHORIZED_PROMISE_URL,
  // Can't have more than one active PUSH_PROMISE per URL.
  QUIC_DUPLICATE_PROMISE_URL,
  // Vary check failed.
  QUIC_PROMISE_VARY_MISMATCH,
  // Only GET and HEAD methods allowed.
  QUIC_INVALID_PROMISE_METHOD,
  // The push stream is unclaimed and timed out.
  QUIC_PUSH_STREAM_TIMED_OUT,
  // Received headers were too large.
  QUIC_HEADERS_TOO_LARGE,
  // No error. Used as bound while iterating.
  QUIC_STREAM_LAST_ERROR,
};
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/19#issuecomment-272895137

---

From: Mike Bishop <[email-masked]>
Date: Mon, 16 Jan 2017 13:36:58 -0800

Several of those are HTTP error codes, not QUIC (transport).  Tagging to make sure I add them to the HTTP draft.  Others look like they're host-local codes (I.e. you don't send RST_STREAM in response to a CONNECTION_CLOSE).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/19#issuecomment-272967612

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 16 Jan 2017 14:36:39 -0800

Good spot, I guess this a case where we'll have to split the Google QUIC
set and apply the application level bits.

On 16 Jan 2017 21:37, "Mike Bishop" <[email-masked]> wrote:

> Several of those are HTTP error codes, not QUIC (transport). Tagging to
> make sure I add them to the HTTP draft. Others look like they're host-local
> codes (I.e. you don't send RST_STREAM in response to a CONNECTION_CLOSE).
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/19#issuecomment-272967612>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AGRFtQYCdM5Hj4JWR8n7PdFNl4AAphoxks5rS-L6gaJpZM4K6f6e>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/19#issuecomment-272977739

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 19 Jan 2017 04:19:07 -0800

I've had another thought, QUIC-TRANSPORT says:

> This section lists the defined QUIC transport error codes that may be used in a CONNECTION_CLOSE or RST_STREAM frame. Error codes share a common code space. Some error codes apply only to either streams or the entire connection and have no defined semantics in the other context.

It's not clear to me what error codes are appropriate to use with which frame types. Google's QUIC implementation separated the error codes into distinct groups, which made things clearer. It was just not documented in the specs.

How should an endpoint handle receiving a frame type that includes an error code that is semantically incorrect. For example, receiving a `RST_FRAME` with an error belonging to the host-local codes?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/19#issuecomment-273762703

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Jan 2017 20:49:38 -0800

@LPardue can you open an issue to track the use of error codes with appropriate messages?

@LPardue, @MikeBishop we can close this now, right?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/19#issuecomment-273976998

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 20 Jan 2017 07:57:31 -0800

@martinthomson 

Would it be more sensible to close this once the error codes have either been defined (in the approprate I-D) or explicitly ignored?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/19#issuecomment-274107194

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 20 Jan 2017 08:09:18 -0800

> @LPardue can you open an issue to track the use of error codes with appropriate messages?

I have create #184 to track this issue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/19#issuecomment-274110255