Describe the impact of priority on other connections #105
Conversation
Priority is mostly within a connection, except when the server knows otherwise.
There was a problem hiding this comment.
How about going like:
A server MUST NOT use the priority values for making schedule decisions across multiple connections, unless it knows that those connections originate from the same client. Due to this, priority information conveyed over a non-coalesced HTTP connection (e.g., HTTP/1.1) might go unused.
A client MAY use the priority values for making local scheduling choices for the requests it initiates.
The intent here is to provide clearer guidance for implementors by starting with subject (i.e. server or client) and then a RFC 2119 verb.
| @@ -240,6 +240,18 @@ compatible for peers that are unaware of the extended meaning. | |||
| The scheme has a single encoding and set of functionality whether it's | |||
| conveyed via a HTTP header or within a frame. | |||
|
|
|||
| ## Impact on other connections | |||
There was a problem hiding this comment.
| ## Impact on other connections | |
| ## Impact on Other Connections |
| @@ -240,6 +240,18 @@ compatible for peers that are unaware of the extended meaning. | |||
| The scheme has a single encoding and set of functionality whether it's | |||
| conveyed via a HTTP header or within a frame. | |||
|
|
|||
| ## Impact on other connections | |||
|
|
|||
| When multiple connections are open, the priority MAY have impact on the | |||
There was a problem hiding this comment.
For my own benefit at least, I would like to understand what exactly "multiple connections" means in this context. There is a difference to multiple HTTP connections to the same authority (something not recommended for H2 or H3) vs multiple connections to different authorities that all compose a page (but are serviced by the same physical machine) vs just the client having multiple TCP connections open .
|
I agree with @kazuho and think his suggested wording would address the comment that I made. |
|
PS. re "a server MUST NOT use the priority values for making schedule decisions across multiple connections," I am starting to wonder if we need to be that strict. One example that will be prohibited by this provision is the use of a different congestion controller for a "background" request. I think it might make sense to change this to SHOULD NOT, expand the Security Considerations to four sub-topics: general discussion on fairness (this PR), coalescing intermediaries (existing section 7.1), HTTP/1 (see #107), and use of different congestion controllers. |
|
Feel free to close this once #110 lands if you'd like. |
Priority is mostly within a connection, except when the server knows otherwise.
Fixes part of #87 and part of #46