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

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.



> @@ -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

This certainly depends on acknowledging that servers can set SETTINGS_NUM_PLACEHOLDERS to zero.

If we look at HTTP/2 implementations, it is my understanding that browsers tend to give higher weight values to resources of higher precedence, regardless of their position in the prioritization tree. This works somewhat reasonably as a fallback when connecting to a server that respects the weights only, because resources of higher precedence would be given more bandwidths that those of lower precedence.

Recommending (or acknowledging) that SETTINGS_NUM_PLACEHOLDERS to be 0 or at least 32 allows a client implementation to consider only two ways of server prioritizing the responses: one being the server respecting the tree build by the client, the other being the tree squeezed and only the weight values being respected.

IMO knowing that the servers are likely to view the prioritization information in either of these two ways is highly preferable for enabling a client to use one design for the prioritization tree it builds _regardless of the value of SETTINGS_NUM_PLACEHOLDERS_, which is IMO the primary goal of this PR.

-- 
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#discussion_r298456876