Date: Tue, 14 Jan 2020 10:36:34 -0800
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+AFTOJK3CSATWMRKDDMD54RN4FM6LFEVBNHHCABYU5A@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3300/574312708@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3300@github.com>
References: <quicwg/base-drafts/issues/3300@github.com>
Subject: Re: [quicwg/base-drafts] Forwarding upstream errors, and the
 implications (#3300)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5e1e0a32c7c60_14353ff69f8cd96467213";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/uRByf-Emtsghqpp_Piu5FAa1YKw>


----==_mimepart_5e1e0a32c7c60_14353ff69f8cd96467213
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

@MikeBishop 
> I'm willing to add cautionary text around the promotion permission, but I think an outright prohibition is both unwise and unenforceable. Implementers will do what they will do, and when there's garbage coming from the peer, it's a totally sensible design to close aggressively.
> 
> Frankly, I'd say CDNs shouldn't be shuffling raw frames anyway; they should be shuttling content, at the very least, and mostly have to anyway for HPACK/QPACK to work (unless everything is literal). At that point, we're really only talking about malformed headers.

It is true that implementations would do whatever they do. To that end, I think it is correct to argue that there is no difference between a MUST NOT and a cautionary text with a clarification on what might happen. We'd have the same design as that in HTTP/2, and having clarification on the side-effects would be an improvement.

I also agree that CDNs shouldn't be shuffling raw frames anyway. That's not something on table. The original issue, for which I am seeing complexity, is about transmitting an error at the same time forwarding all the bytes up to where the error was detected. As previously stated, doing that has become much more complicated in HTTP/3 compared to HTTP/2. That said, it's not impossible, and if others implementing proxies are happy with living with such an workaround (or do not care about the problem), I can concede with that workaround.

Re malformed headers, I am starting to wonder the intent. Which of the following two are we suggesting?
* headers considered malformed in the HTTP/3 specification
* headers consider malformed by the specifications that define those headers

If it's the latter, it would be impossible for an HTTP/3 intermediary to detect all the malformed headers (consider the case of a new HTTP extension defining a authentication header - a type of header field that is forbidden from being sent as part of a trailer). Maybe it's a good idea to clarify that it is the former, assuming that that is the intent.

-- 
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/3300#issuecomment-574312708
----==_mimepart_5e1e0a32c7c60_14353ff69f8cd96467213
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/users/MikeBishop/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/MikeBishop">@MikeBishop</a></p>
<blockquote>
<p>I'm willing to add cautionary text around the promotion permission, but I think an outright prohibition is both unwise and unenforceable. Implementers will do what they will do, and when there's garbage coming from the peer, it's a totally sensible design to close aggressively.</p>
<p>Frankly, I'd say CDNs shouldn't be shuffling raw frames anyway; they should be shuttling content, at the very least, and mostly have to anyway for HPACK/QPACK to work (unless everything is literal). At that point, we're really only talking about malformed headers.</p>
</blockquote>
<p>It is true that implementations would do whatever they do. To that end, I think it is correct to argue that there is no difference between a MUST NOT and a cautionary text with a clarification on what might happen. We'd have the same design as that in HTTP/2, and having clarification on the side-effects would be an improvement.</p>
<p>I also agree that CDNs shouldn't be shuffling raw frames anyway. That's not something on table. The original issue, for which I am seeing complexity, is about transmitting an error at the same time forwarding all the bytes up to where the error was detected. As previously stated, doing that has become much more complicated in HTTP/3 compared to HTTP/2. That said, it's not impossible, and if others implementing proxies are happy with living with such an workaround (or do not care about the problem), I can concede with that workaround.</p>
<p>Re malformed headers, I am starting to wonder the intent. Which of the following two are we suggesting?</p>
<ul>
<li>headers considered malformed in the HTTP/3 specification</li>
<li>headers consider malformed by the specifications that define those headers</li>
</ul>
<p>If it's the latter, it would be impossible for an HTTP/3 intermediary to detect all the malformed headers (consider the case of a new HTTP extension defining a authentication header - a type of header field that is forbidden from being sent as part of a trailer). Maybe it's a good idea to clarify that it is the former, assuming that that is the intent.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/quicwg/base-drafts/issues/3300?email_source=notifications&amp;email_token=AFTOJK4LJSVRINCP4BCDFLTQ5YA3FA5CNFSM4J2HSDB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI5VCBA#issuecomment-574312708">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AFTOJK6URONXO7625IGURVLQ5YA3FANCNFSM4J2HSDBQ">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AFTOJK73RBVJS4ZAXVOJZTDQ5YA3FA5CNFSM4J2HSDB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI5VCBA.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/3300?email_source=notifications\u0026email_token=AFTOJK4LJSVRINCP4BCDFLTQ5YA3FA5CNFSM4J2HSDB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI5VCBA#issuecomment-574312708",
"url": "https://github.com/quicwg/base-drafts/issues/3300?email_source=notifications\u0026email_token=AFTOJK4LJSVRINCP4BCDFLTQ5YA3FA5CNFSM4J2HSDB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI5VCBA#issuecomment-574312708",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_5e1e0a32c7c60_14353ff69f8cd96467213--