Re: [quicwg/base-drafts] allow PRIORITY frames referring to placeholders exceeding `SETTING_NUM_PLACEHOLDERS` (#2761)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> @@ -613,17 +613,17 @@ tree could be discarded safely. Clients could potentially reference closed
 streams long after the server had discarded state, leading to disparate views of
 the prioritization the client had attempted to express.
 
-In HTTP/3, a number of placeholders are explicitly permitted by the server using
-the `SETTINGS_NUM_PLACEHOLDERS` setting. Because the server commits to
-maintaining these placeholders in the prioritization tree, clients can use them
-with confidence that the server will not have discarded the state. Clients MUST
-NOT send the `SETTINGS_NUM_PLACEHOLDERS` setting; receipt of this setting by a
-server MUST be treated as a connection error of type
+In HTTP/3, placeholders are given their own number space that spans between zero
+and 2^62-1.  By using the `SETTINGS_NUM_PLACEHOLDERS` setting, the server
+advertises the range of placeholder IDs it is committing to maintain state,

"advertises the number of placeholder IDs for which it is committing to maintain state."

> @@ -613,17 +613,17 @@ tree could be discarded safely. Clients could potentially reference closed
 streams long after the server had discarded state, leading to disparate views of
 the prioritization the client had attempted to express.
 
-In HTTP/3, a number of placeholders are explicitly permitted by the server using
-the `SETTINGS_NUM_PLACEHOLDERS` setting. Because the server commits to
-maintaining these placeholders in the prioritization tree, clients can use them
-with confidence that the server will not have discarded the state. Clients MUST
-NOT send the `SETTINGS_NUM_PLACEHOLDERS` setting; receipt of this setting by a
-server MUST be treated as a connection error of type
+In HTTP/3, placeholders are given their own number space that spans between zero
+and 2^62-1.  By using the `SETTINGS_NUM_PLACEHOLDERS` setting, the server
+advertises the range of placeholder IDs it is committing to maintain state,
+which is between zero and one less than the value of this setting.  Clients can
+use the placeholders within this range with the confidence that the server will

"can use placeholders with an ID less than the value of this setting with...."

> @@ -1202,9 +1202,17 @@ The following situations are examples of invalid PRIORITY frames:
 A PRIORITY frame with Empty bits not set to zero MAY be treated as a connection
 error of type HTTP_MALFORMED_FRAME.
 
-A PRIORITY frame that references a non-existent Push ID, a Placeholder ID
-greater than the server's limit, or a Stream ID the client is not yet permitted
-to open MUST be treated as a connection error of type HTTP_LIMIT_EXCEEDED.
+A PRIORITY frame that references a non-existent Push ID, or a Stream ID the

```suggestion
A PRIORITY frame that references a non-existent Push ID or a Stream ID the
```

> @@ -1202,9 +1202,17 @@ The following situations are examples of invalid PRIORITY frames:
 A PRIORITY frame with Empty bits not set to zero MAY be treated as a connection
 error of type HTTP_MALFORMED_FRAME.
 
-A PRIORITY frame that references a non-existent Push ID, a Placeholder ID
-greater than the server's limit, or a Stream ID the client is not yet permitted
-to open MUST be treated as a connection error of type HTTP_LIMIT_EXCEEDED.
+A PRIORITY frame that references a non-existent Push ID, or a Stream ID the
+client is not yet permitted to open MUST be treated as a connection error of
+type HTTP_LIMIT_EXCEEDED.
+
+A PRIORITY frame MAY reference a Placeholder ID that is equal to or greater than
+the server's advertised value of the `SETTINGS_NUM_PLACEHOLDERS` settings.  When
+receiving a PRIORITY frame with its prioritized element set to such a
+placeholder, the server SHOULD discard the frame without making any change to
+the priority tree.  When receiving a PRIORITY frame with its element dependency
+set to such a placeholder, the server SHOULD update the priority tree with the
+root of the tree being the dependency instead.

I feel like the orphan makes more sense -- just because the client is assigning *a* priority doesn't imply that it's assigning a *high* priority.  The implication would be that clients should build the priority tree with higher-priority placeholders having a lower placeholder ID.  At some point, the placeholder IDs cross the threshold of what the server supports, and everything in that tree region devolves to "after everything else."  That seems like a reasonable degradation path.

-- 
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/2761#pullrequestreview-246859283