Subject: [quicwg/base-drafts] Error Code when SETTINGS exceeds maximum (#2498)

From: martinduke <[email-masked]>
Date: Tue, 05 Mar 2019 14:29:03 -0800

The HTTP draft doesn't have any SETTINGS parameters with a maximum value, but QPACK does.  I don't see any text in hpack sec. 4.2.5.1 or qpack sec 5 that explains what to do if we receive a parameter that exceeds the maximum parameter.

-- 
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/2498

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 05 Mar 2019 23:06:16 +0000 (UTC)

Good observation. This is another case where MALFORMED_FRAME is not appropriate. 

I might reset the peer-initiated stream with HTTP_LIMIT_EXCEEDED, which would prompt the other end to close the connection HTTP_CLOSED_CRITICAL_STREAM.

An alternative is just CONNECTION_CLOSE with HTTP_GENERAL_PROTOCOL_ERROR. 

... or We could invoke the YAEC label :)

Whatever we decide, I think it needs documenting.

-- 
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/2498#issuecomment-469895669

---

From: Mike Bishop <[email-masked]>
Date: Wed, 06 Mar 2019 14:47:36 -0800

Technically, you can't reset a peer-initiated stream, just STOP_SENDING.

-- 
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/2498#issuecomment-470308460

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 06 Mar 2019 15:19:46 -0800

That's an astute observation and something I've missed. Perhaps I'm missing it but the spec doesn't say how to handle a STOP_SENDING received on a control stream. Should this peer issue a RESET_STREAM in response (causing the other peer to blow up) or should it just close the connection itself?

-- 
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/2498#issuecomment-470316968

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 06 Mar 2019 19:00:30 -0800

My understanding is that STOP_SENDING is an act of closing a stream rather than an advisory signal.
Based on that, I'd argue that receipt of STOP_SENDING on a critical stream should trigger a HTTP_CLOSED_CRITICAL_STREAM connection-level 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/2498#issuecomment-470365248

---

From: MikkelFJ <[email-masked]>
Date: Wed, 06 Mar 2019 23:53:39 -0800

I don’t think that STOP_SENDING terminates a stream per se, but an application can choose to interpret it as such, so HTTP/3 can make that call.

-- 
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/2498#issuecomment-470422800

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 07 Mar 2019 12:56:06 -0800

To be precise, STOP_SENDING "_typically indicates that the receiving application is no longer reading data it receives from the stream_, but it is not a guarantee that incoming data will be ignored" ([transport daft section 3.5](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.3.5)).

Because there is a chance of it indicating that the peer is no longer reading, STOP_SENDING received on a critical stream ought to trigger a HTTP_CLOSED_CRITICAL_STREAM 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/2498#issuecomment-470690647

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 07 Mar 2019 13:05:00 -0800

I'd be happy with MUST close connection in response

-- 
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/2498#issuecomment-470693554