Subject: [quicwg/base-drafts] H3 guidance on malformed request/response is light (#2410)

From: Lucas Pardue <[email-masked]>
Date: Mon, 04 Feb 2019 08:18:46 -0800

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

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 04 Feb 2019 16:35:34 +0000 (UTC)

Some further info. In H2, malformed request/response causes a stream error of type PROTOCOL_ERROR. The H3 draft says:

> PROTOCOL_ERROR (0x1):
    No single mapping. See new HTTP_MALFORMED_FRAME error codes defined in Section 8.1.

But errors in this category are not caused by a problem with the frames themselves. 

Fortunately, we have H3 HTTP_GENERAL_PROTOCOL_ERROR, which seems like the correct thing to use in this case. But nowhere in the draft is this ever referred to, so its easy to miss.

-- 
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/2410#issuecomment-460316786

---

From: Luca Niccolini <[email-masked]>
Date: Mon, 04 Feb 2019 08:41:08 -0800

FRAME related errors are defined at the end of S8.1. 
However that is going to change due to #2253 
 
```
HTTP_MALFORMED_FRAME (0x01XX):
An error in a specific frame type. The frame type is included as the last byte of the error code. For example, an error in a MAX_PUSH_ID frame would be indicated with the code (0x10D).
```

-- 
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/2410#issuecomment-460318985

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 04 Feb 2019 09:01:33 -0800

Nice catch!

I think I'd prefer using HTTP_GENERAL_PROTOCOL_ERROR or an error code just for this purpose rather than HTTP_MALFORMED_FRAME, because this is a framing error in the HTTP semantic layer, rather than an error in a HTTP/3 frame. The issue with using HTTP_MALFORMED_FRAME becomes most apparent when the request body is shorter than the sum of DATA frames, and if there is a trailer, the error will be detected when seeing the HEADERS frame. It would be strange to report the issue as HTTP_MALFORMED_FRAME(HEADERS) (because it's not an issue with the HEADERS frame), or as HTTP_MALFORMED_FRAME(DATA) (because none of the DATA frames that the client sent was malformed.

-- 
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/2410#issuecomment-460326784

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 04 Feb 2019 09:10:31 -0800

PS. and my preference goes to having an error code just for this purpose, named as HTTP_RESPONSE_CANCELLED, or something similar.

As a reverse proxy developer, whenever the upstream server closes the response abruptly, I try to forward that error to the client. H2 does not have an error code for that, and we use PROTOCOL_ERROR for that. But the error code misses the fact that the error happened elsewhere than between the client and the server that is using H2, which _is_ confusing.

-- 
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/2410#issuecomment-460330192

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 04 Feb 2019 10:01:33 -0800

Another error that we saw a lot in the early days of H2 deployment was headers fields using mixed-case capitalization. This cannot be attributed to a malformed H3 frame. 

I really hope this class of error has been shaken out of systems by now but you never know.

-- 
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/2410#issuecomment-460348562

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 05 Feb 2019 19:05:41 +0000 (UTC)

@LPardue 
> I really hope this class of error has been shaken out of systems by now but you never know.

Agreed. I think using HTTP_GENERAL_PROTOCOL_ERROR as a catch-all error code when the peer does something stupid makes sense. After all, that's what we did in H2 and IMO it works well.

-- 
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/2410#issuecomment-460762950

---

From: Mike Bishop <[email-masked]>
Date: Tue, 05 Feb 2019 16:51:01 -0800

I think this falls under the umbrella of making sure RFC7540 content is referenced / restated appropriately in an H3 world.

-- 
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/2410#issuecomment-460863185