Skip to content

Roughing out reprioritization

Jump to bottom
Lucas Pardue edited this page Jul 3, 2019 · 3 revisions

Rough ideas for how to reprioritize in the header-based priority world.

Problem: how to request reprioritizion of responses that are in flight? Once a request is sent, there is no way to send more Priority headers.

A new frame

Define a new extension frame HEADER-PRIORITY that carries the priority information in accordance with this specification e.g. priority directives. Making this a non-critical extension frame means that it can be safely ignored by endpoints that don't know it. Combining with SETTINGS_HEADER_BASED_PRIORITY setting may improve chances of success.

For the frame payload, some options spring to mind:

  1. Header-block:
  • HEADER-PRIORITY contains a HPACK-encoded header block that is only allowed to represent a header list consiting of "Priority" headers.
  • Extension: very similar to HTTP semantic. Simple to add new priority-related headers. Ignore unknown headers, blow up unknown headers that are not explicitly allowed in frame(?).
  • Pros: save some bandwidth by reusing compression context
  1. ALTSVC-style:

  • A sequence of octets (length determined by subtracting the length of all preceding fields from the frame length) containing a value identical to the Alt-Svc field value defined in Section 3 (ABNF production "Alt-Svc").

  • So HEADER-PRIORITY contains the ABNF production of "Priority" header.
  • Extension: harder to extend the contents, combination would need delimitation. Solvable by defining a new extension frame for each type of priority-related-header extension.
  1. SETTINGS style:
  • The frame carries HEADER-PRIORITY parameters.
  • General problem: duplication of header-style meaning two sets of specification types and parser
  • Extension: unknown parameters are ignored.

@LPardue preference at time of writing is option 1.

Using a HEADER-PRIORITY frame

A HEADER-PRIORITY frame needs to identify the resource that it can reprioritize. The initial suggestion is that the frame is sent on the control stream and carries a Stream ID related to the response that is the target for reprioritization. Aside: sending this frame on the request stream is not feasible because the client closes stream once it finalizes the request. Changing this is a critical HTTP/2 behaviour extension and will have friction to adoption.

Server push

If this approach is taken, it has a nice side-effect for server push. A server can send PUSH_PROMISE frames that indicate the initial priority that they will be using. The default would be to inherit the priority of the parent request but server's can override this with their suggestion. A client that wants to modify the push priority (either to explicitly change it away from the default, or to override the server suggestion) can send a HEADER-PRIORITY frame on the control stream which references the Push stream ID.

Clone this wiki locally