Hop-by-hop emulation with end-to-end headers

[MikeBishop]

Not necessarily an issue; more that I wanted to sketch out the idea I had during the call a few weeks ago.

The application of any prioritization is within the context of either the connection or the server itself. The server's cross-connection prioritization is open enough to gaming (my requests are always more important than yours!) that I feel like we should specifically advise against it and design solely for intra-connection prioritization.

I think there are three key values to be transported across each hop:

• HTTP-Priority (C2S): Expresses the client's preference for how the response is handled on this connection.
• Original-HTTP-Priority (C2S): Carries the user agent's preference for how the response is handled on the user-to-first-intermediary connection (which is not this one).
• HTTP-Priority (S2C): Expresses the server's preference for how the response is handled on downstream connections, if any

Processing rules would be that each of these headers is end-to-end, with one key exception: intermediaries MAY replace the HTTP-Priority value with their own preferences when making upstream requests. If they do so and there isn't an Original-HTTP-Priority header already, they SHOULD copy the original value to the Original-HTTP-Priority header. An intermediary that wants to use this scheme upstream, but did not receive an HTTP-Priority header from the client should add an "Original-HTTP-Priority: (none)" header field.

There's a fourth value that is probably not worth putting on the wire, which is what the server (on a given connection) has actually chosen to do on this connection. That's an implementation artifact, and it doesn't need to get shared outside its code. The S2C header is useful, however, if the server wants to override what the client said or provide cachable guidance about how a cached version of this response should be sent to clients in the future, even in the absence of guidance from that future client.

Each intermediary is looking at the suggested policies from its client (which might not be the user agent) and from the server and choosing what policy to apply in an implementation-dependent manner.

[rmarx]

I personally really like this design, but not sure we should limit to "intra-connection".

Given the continuous discussion on the "coalescing"/"cross-connection" use case both here and during the design team's meetings, I don't think it's a good idea just leaving it out, since it's clearly something people are thinking of (even though that never materialized for H2...)

As I mentioned in https://github.com/kazuho/draft-kazuho-httpbis-priority/pull/56#issuecomment-548892433, it might be interesting to have an explicit signal for that as well to help deal with this case. Alternatively, intermediaries that aggregate, can be (strongly) encouraged to override HTTP-Priority to "concurrency=0, progressive=?1" as suggested by Kazuho in #56 (this would have my preference).

[kazuho]

@MikeBishop Thank you for raising the issue. I think that the proposed approach is useful for a server only when:

• all the intermediaries back to the client implements this specification (see https://github.com/kazuho/draft-kazuho-httpbis-priority/pull/56#issuecomment-549009940), and
• some of the intermediaries coalesce requests from different connections

Based on this observation, I wonder the probability of seeing servers actually benefitting from the proposed design. Therefore, if we are going to let intermediaries express there own priorities, then I think I'd prefer that being done in a less intrusive way. Specifically, by adding an element to the priority header using the 1# rule, while using ; as the separator between the priority attributes.

For example, the end client says Priority: urgency=-1; progressive=?1, then an intermediary that changes the urgency to 0 would append its own and change the header to Priority: urgency=-1; progerssive=?1, urgency=0.

Invocation of #1 rule reduces the complexity of the intermediaries too, because it removes the requirement to rewrite the request headers. Instead, the intermediary can set it's priority as a new header on wire (which is logically an element according to #1 rule).

[ianswett]

I think we decided to not do this, but like the "Are headers hop-by-hop?" issue I opened, it'd be good to document what we discussed.