Barry Leiba's HTTP/3 Discuss 1

[LPardue]

@barryleiba said

In Section 4.1.1 I’m confused by the combination of the following two
paragraphs, and would like to discuss what I’m missing:

Like HTTP/2, HTTP/3 does not use the Connection header field to
indicate connection-specific fields; in this protocol, connection-
specific metadata is conveyed by other means. An endpoint MUST NOT
generate an HTTP/3 field section containing connection-specific
fields; any message containing connection-specific fields MUST be
treated as malformed (Section 4.1.3).

...

This means that an intermediary transforming an HTTP/1.x message to
HTTP/3 will need to remove any fields nominated by the Connection
field, along with the Connection field itself. Such intermediaries
SHOULD also remove other connection-specific fields, such as Keep-
Alive, Proxy-Connection, Transfer-Encoding, and Upgrade, even if they
are not nominated by the Connection field.

Given the MUST in the first, how can the second only be SHOULD? Wouldn’t such
an intermediary, acting as the HTTP/3 client, be producing a malformed message
if it did not “remove other connection-specific fields”?

[MikeBishop]

@barryleiba, This is text imported mostly-unchanged from RFC7540, but I'm always happy to improve upon the past. This point actually came up in the discussion of #4747, which is rewording that paragraph slightly, but your point would still remain with the new text.

The key is that HTTP fields are an extension point, and some fields are defined to have hop-by-hop semantics. The endpoint necessarily knows the meaning of all fields it generates, and so we can tell it that it MUST NOT generate a field with hop-by-hop semantics. However, the intermediary does not necessarily know the meaning of all fields some other endpoint sends through it. Another way to read this is "MUST remove all fields which are known to have hop-by-hop semantics, but we acknowledge you might miss some"; that's a difficult requirement to test. We've tended to use SHOULD for unenforceable MUSTs throughout these documents.

If you'd like to suggest a better way to phrase it, I'm open to incorporating it into #4747 or a follow-up.

[martinthomson]

As @mnot pointed out in httpwg/http2-spec#804, the core HTTP spec now has the same rules, written more clearly. We should just reference them.

[barryleiba]

That WFM. Barry

…

On Wed, Jan 20, 2021 at 5:17 PM Martin Thomson ***@***.***> wrote: As @mnot <https://github.com/mnot> pointed out <httpwg/http2-spec#804 (comment)> in httpwg/http2-spec#804 <httpwg/http2-spec#804>, the core HTTP spec now has the same rules <https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#field.connection>, written more clearly. We should just reference them. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4771 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5SDLKGKKOFL56DAQUCNG3S25I7TANCNFSM4WK5OF3Q> .

[MikeBishop]

#4747 now includes the same text as httpwg/http2-spec#804.

[barryleiba]

Great; sounds like I'll be moving to a Yes ballot when I see the revised draft posted. Thanks, Mike, and all. Barry

…

On Thu, Jan 21, 2021 at 11:41 AM Mike Bishop ***@***.***> wrote: #4747 <#4747> now includes the same text as httpwg/http2-spec#804 <httpwg/http2-spec#804>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4771 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5SDLPHSGOL6WIP6I5M4ATS3BKJ7ANCNFSM4WK5OF3Q> .