Subject: [quicwg/base-drafts] HTTP-31: Minor Editorial Issues (#4232)

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Oct 2020 08:14:07 -0700

These are some minor editorial things that should be considered to be addressed:

1. Section 4.1: "A server MAY send one or more PUSH_PROMISE frames (Section 7.2.5) before, after, or interleaved with the frames of a response message. These PUSH_PROMISE frames are not part of the response; see Section 4.4 for more details. These frames are not permitted in pushed responses; a pushed response that includes PUSH_PROMISE frames MUST be treated as a connection error of type H3_FRAME_UNEXPECTED." Especially the third sentence was hard to parse. Took me a while to realize that it tries to express that PUSH_PROMISE frames are not allowed in pushed responses. I think it is primarily a language thing. However, isn't this dependent on stream type. So PUSH_PROMISE are allowed on the client-initiated bi-directional stream but not on the server-initiated unidirectional stream. 
2. Section 4.1.1: "For a listing of registered HTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at https://www.iana.org/assignments/http-fields/." To avoid more confusion like the one I had in IETF last call. Can you add an Editors note (to be removed before RFC publication) that this registry does not yet exist, and is dependent on approval of [SEMANTICS]?
3. Section 7.2.4.1: "SETTINGS_MAX_FIELD_SECTION_SIZE (0x6): The default value is unlimited. See Section 4.1.1 for usage." As the actual discussion of usage of this setting is in Section 4.1.1.3 wouldn't that be better to reference?

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

---

From: Mike Bishop <[email-masked]>
Date: Fri, 16 Oct 2020 12:38:07 -0700

1.  I'll take a look at cleaning it up, but I'm hesitant to simply say "can't be used on unidirectional streams" because an extension might create a unidirectional stream that does allow PUSH_PROMISE frames for whatever reason.  Maybe specifically stating that they can't be sent on Push Streams would work?
2.  Good suggestion.
3.  Good suggestion; probably we moved this text to subsections after the reference was written.

-- 
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/4232#issuecomment-710493027

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 16 Oct 2020 13:18:54 -0700

1. My personal view has been that PUSH_PROMISE is part of a request message. And so it has to abide by the rules there. Any attempt to change that requires a semantic extension to H3. Which is what https://tools.ietf.org/html/draft-pardue-quic-http-unbound-server-push-01 precisely does in order to allow PUSH_PROMISE on a new stream type.

-- 
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/4232#issuecomment-710554899

---

From: Mike Bishop <[email-masked]>
Date: Sun, 18 Oct 2020 19:34:58 -0700

Closed #4232 via 6890ba562653f39d58620b713b59eef6929e5de1.

-- 
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/4232#event-3891046954