HTTP: Limit priority state before stream is opened

[dtikhonov]

RFC 7540 discusses priority state management at some length, especially what to do with priority information after a stream is closed.

In addition to this, in HTTP/3, we have to deal with priority information before a stream is opened. That is: just how large is the tree allowed to grow before the referenced streams' frames begin to come in?

The draft should provide some recommendations.

I can think of two ways to do limit this "front-loaded" state:

1. Open the stream when a PRIORITY frame referencing it arrives on the control stream. This will invoke the stream limit checks.
2. Limit number of priority entries to number -- perhaps a function of the total number of maximum unidirectional and bidirectional streams.

[martinthomson]

Just clarifying: this would be advice to implementations, nothing normative, right?

[dtikhonov]

I don't know. I think I will be happy as long as something is put into the draft.

[MikeBishop]

Assuming that PRIORITY can only reference a stream that already "exists" client-side, the maximum number would be the number of permitted client-initiated bidirectional streams. Perhaps the requirements should simply be that PRIORITY cannot reference a stream that the client isn't permitted to open?

I don't really want to "actually open" the stream when the PRIORITY frame arrives, but checking that it's less than the MAX_STREAM_ID on receipt seems like a reasonable server-side check.