Subject: [quicwg/base-drafts] clarify the use of an incomplete DATA frame to forward a malformed partial message (#3303)

From: Kazuho Oku <[email-masked]>
Date: Mon, 16 Dec 2019 17:07:40 -0800

Clarifies that a tunnel might intentionally use an incomplete DATA frame to forward a malformed response, while preserving the partial response that has been transferred.

closes #3300.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3303

-- Commit Summary --

  * clarify the use of an incomplete DATA frame to forward a malformed partial message

-- File Changes --

    M draft-ietf-quic-http.md (9)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3303.patch
https://github.com/quicwg/base-drafts/pull/3303.diff

-- 
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/pull/3303

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Dec 2019 17:45:17 -0800

@kazuho pushed 1 commit.

1fe230aec999e6fc6810d208ae388faed77da413  reorder the paragraph so that the text discussing about non-tunnels and tunnels sit next to each other

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3303/files/83f83ce6583dbbba235ca2ef5b9d6201a67f54ab..1fe230aec999e6fc6810d208ae388faed77da413

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Dec 2019 17:50:35 -0800

Seeing distaste for endorsing an intermediary to send a corrupt frame intentionally, I have changed the text to be a clarification of what we already have.

The paragraph that precedes the new paragraph being proposed in this PR states that, quote: "Intermediaries that process HTTP requests or responses (i.e., any intermediary
not acting as a tunnel) MUST NOT forward a malformed request or response."

The flip-side is that tunnels are allowed to send malformed HTTP messages. As a tunnel might be coalescing messages from multiple endpoints onto a single connection, receipt of a malformed HTTP message cannot be considered as a connection-level issue.

This PR clarifies that.

-- 
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/pull/3303#issuecomment-566830111

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 17 Dec 2019 18:52:14 -0800

RyanAtGoogle approved this pull request.

-- 
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/pull/3303#pullrequestreview-333703851

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 17 Dec 2019 20:01:00 -0800

janaiyengar commented on this pull request.

> @@ -536,6 +536,11 @@ not acting as a tunnel) MUST NOT forward a malformed request or response.
 Malformed requests or responses that are detected MUST be treated as a stream
 error ({{errors}}) of type H3_GENERAL_PROTOCOL_ERROR.
 
+A tunnel that dispatches HTTP messages to different endpoints might forward a

```suggestion
An intermediary acting as a tunnel could carry HTTP messages from multiple endpoints on one side to a single endpoint on the other side within a single HTTP/3 connection. Such an intermediary might forward malformed HTTP messages as well. To limit the scope of damage to the offending endpoint, an endpoint that detects a malformed request or response MUST NOT escalate this error to a  connection-level error unless specified otherwise.
```

-- 
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/pull/3303#pullrequestreview-333718498

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 17 Dec 2019 20:01:25 -0800

Editorial suggestion, but this new scoping helps -- thanks!

-- 
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/pull/3303#pullrequestreview-333718573

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Dec 2019 20:21:09 -0800

martinthomson commented on this pull request.

I think that this is a "cannot" rather than a "MUST NOT".  What that intermediary does is up to them.  It might be inadvisable to have errors from one source affect all of the sources that share the same connection, but that's their 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/pull/3303#discussion_r359146165

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Dec 2019 21:01:43 -0800

@kazuho pushed 1 commit.

08a32c4f074ec46655eeb2534138e694e06a4d91  Update draft-ietf-quic-http.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3303/files/1fe230aec999e6fc6810d208ae388faed77da413..08a32c4f074ec46655eeb2534138e694e06a4d91

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Dec 2019 21:03:00 -0800

kazuho commented on this pull request.

@janaiyengar Thank you for the suggestion. Applied.

@martinthomson Yeah, MUST NOT applies to what the endpoint does when it receives a malformed message from the peer which _might_ be an intermediary.

-- 
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/pull/3303#discussion_r359153466

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Dec 2019 21:13:38 -0800

@kazuho pushed 1 commit.

3bcce5f41d3437f8803d3b5bd7594992ddbad6b4  wordwrap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3303/files/08a32c4f074ec46655eeb2534138e694e06a4d91..3bcce5f41d3437f8803d3b5bd7594992ddbad6b4

---

From: ianswett <[email-masked]>
Date: Wed, 18 Dec 2019 07:51:28 -0800

ianswett approved this pull request.

-- 
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/pull/3303#pullrequestreview-334071603

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Dec 2019 23:16:53 -0800

Please fix the PR title. 

-- 
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/pull/3303#issuecomment-567819403

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 20 Dec 2019 03:34:25 -0800

@martinthomson Does something like "Receipt of malformed message is a stream-level error, as a tunnel might forward them" sounds OK to you?

-- 
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/pull/3303#issuecomment-567895372

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 20 Dec 2019 12:26:46 -0800

@kazuho: I'll suggest "Clarify behavior for HTTP tunnels" as a better title

-- 
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/pull/3303#issuecomment-568076440

---

From: Martin Thomson <[email-masked]>
Date: Fri, 20 Dec 2019 14:06:40 -0800

Either works. "Forwarding status of errors on streams"

-- 
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/pull/3303#issuecomment-568105292

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 22 Dec 2019 23:52:56 -0800

@martinthomson Thank you for the suggestion. Done.

-- 
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/pull/3303#issuecomment-568391914

---

From: ianswett <[email-masked]>
Date: Mon, 23 Dec 2019 06:48:59 -0800

ianswett requested changes on this pull request.

The more I look at this, the more I wonder what the full impact is.  It ends up precluding a wide set of errors from becoming connection level errors in order to deal more gracefully with buggy implementations or inadvertent disconnects.

How about scoping this down only to cases when the stream is abruptly terminated(ie: reset) and not all the data was transferred.

-- 
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/pull/3303#pullrequestreview-335889496

---

From: Mike Bishop <[email-masked]>
Date: Fri, 27 Dec 2019 08:06:52 -0800

@ianswett, that case is already covered by the current text.  A stream can be reset mid-frame, and that's fine.  The problem is that the contents might be invalid, or the intermediary might want to reliably deliver the terminated payload.

-- 
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/pull/3303#issuecomment-569297911