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

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -633,18 +633,22 @@ 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, by using the `SETTINGS_NUM_PLACEHOLDERS` setting, the server
+advertises the number of client-controlled placeholders for which it is
+committing to maintain state.  Client-controlled placeholders are given their
+own number space that spans between zero and 2^62-1.  Clients can use the
+client-controlled placeholders with an ID less than the value of this setting
+with the confidence that the server will not have discarded the state.  The
+orphan placeholder cannot be prioritized or referenced by the client.
+
+Servers are RECOMMENDED to support at least 32 placeholders.  Those that do not

```suggestion
Servers SHOULD support at least 32 placeholders.  Those that do not
```

> @@ -633,18 +633,22 @@ 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, by using the `SETTINGS_NUM_PLACEHOLDERS` setting, the server
+advertises the number of client-controlled placeholders for which it is
+committing to maintain state.  Client-controlled placeholders are given their
+own number space that spans between zero and 2^62-1.  Clients can use the
+client-controlled placeholders with an ID less than the value of this setting
+with the confidence that the server will not have discarded the state.  The

```suggestion
with the confidence that the server will discarded associated state.  The
```

Question, if we have PlaceholderN->RequestN->root in a tree and RequestN has long since been discarded; is this considered "discarding the state"?

> -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, by using the `SETTINGS_NUM_PLACEHOLDERS` setting, the server
+advertises the number of client-controlled placeholders for which it is
+committing to maintain state.  Client-controlled placeholders are given their
+own number space that spans between zero and 2^62-1.  Clients can use the
+client-controlled placeholders with an ID less than the value of this setting
+with the confidence that the server will not have discarded the state.  The
+orphan placeholder cannot be prioritized or referenced by the client.
+
+Servers are RECOMMENDED to support at least 32 placeholders.  Those that do not
+SHOULD refrain from supporting placeholders at all, setting
+`SETTINGS_NUM_PLACEHOLDERS` to zero.

I find this weird.  I would strike the second sentence entirely and consider replacing it with justification for 32.

> @@ -1224,9 +1228,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

```suggestion
placeholder, the server MAY discard the frame without making any change to
```
Note that the setting is loosely defined, as is the size of the priority tree.  A server might allow placeholders above its limit.

> @@ -1224,9 +1228,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

```suggestion
set to a discarded placeholder, the server SHOULD update the priority tree with the
```

Note that this isn't any different than referring to a long-expired 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/2761#pullrequestreview-254323999