When to apply pre-request PRIORITY_UPDATE frames

[dtikhonov]

The priorities draft states:

Request-stream variant PRIORITY_UPDATE frames (type=0xF0700) received before the request or response has started SHOULD be buffered until the stream is opened and applied immediately after the request message has been processed.

Because server may reply with a Priority field of its own based on priority information, it is better to apply the pre-request PRIORITY_UPDATE frame before the server begins to process the request.

[LPardue]

I'm not sure how that helps because my view is that the priority only matters when there are response bytes to send.

An intermediary that receives a PRIORITY_UPDATE as an initial priority signal might chose to add that information to the request it sends on to the server. It can make that decision while processing the request.

[dtikhonov]

I'm not sure how that helps because my view is that the priority only matters when there are response bytes to send.

Even if that's true (which is a different topic!), how do you know that the server does not have bytes to send as soon as it's processed the request? If it has stale priority information (due to a yet-unprocessed PRIORITY_FRAME), it may issue an incorrect Priority response.

An intermediary complicates the picture. The original issue is just about the client - server exchange.

[LPardue]

If a server has a fresh PRIORITY_UPDATE in a buffer, and it's processing the request that it applies to, then not using the PRIORITY_UPDATE seems like a poor implementation choice. So is the problem that a server-local priority decision would benefit from having client-signalled priority while processing the request?

[dtikhonov]

Our conversation has devolved to the point where we go in circles. This is likely because we mean different things by what "the request message has been processed" means.

My understanding of this is that the user code (sitting one level higher than the HTTP code) has processed the request. In that case, the point I am making is that applying priority update afterward is suboptimal. Note that the user code does not have direct access to the incoming PRIORITY_UPDATE frames -- at least not directly. This is why changing the request's "urgency" and "incremental" properties should occur before the user code starts handling the request.

My mental model is based on lsquic, so it the above is natural to me. What kind of model do you have?

[LPardue]

@dtikhonov I aplogize because I think you've hit an issue where the Editor's copy does not reflect the most up-to-date markdown. This is partly my source of confusion in the dicussion. I don't know why this has happened. @mnot or @martinthomson might be able to provide insight.

I beleive we have already merged text that tackles your issue, please see 8b665dc#diff-fa11e89c5392765dabb3b9a9047381abR342 which was done to resolve #1260

[dtikhonov]

Oh yeah: the web page is a stale version of the draft! I will now reference a git-cloned copy. Thanks.

Yes: the new text addresses my concern. I will close this bug.