Intermediaries modifying Priority header fields

[martinthomson]

If intermediaries want to specify prioritization on a multiplexed HTTP connection, they SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field.

Recommendations like this generally need more discussion about why this might be a good idea. Otherwise, they will be ignored. It seems to me like this is a great example of a recommendation that an intermediary will be happy to ignore.

[LPardue]

I don't have much inspiration with regards to an answer here, @kazuho has better experience in this area

[kazuho]

This is keen observation.

It seems that this recommendation went in as part of kazuho/draft-kazuho-httpbis-priority#111, with the rationale being kazuho/draft-kazuho-httpbis-priority#111 (comment).

Reading the rationale, I tend to wonder if this recommendation is part of the debate between hop-by-hop signal vs. end-to-end signal. Now that we agreed that we should support both, maybe we should change here as well, state that intermediaries can modify the Priority header field (if it wants to change the end-to-end signal), or send a PRIORITY_UPDATE frame (if it wants to send a hop-by-hop signal).

WDYT? cc @ianswett

[ianswett]

Conceptually, I prefer the idea that intermediaries should use the frame and endpoints should use the header, because the frame is a connection-level concept and the header is end-to-end.

The practical benefit of this is that if I had an h2/h3 backend connection as an intermediary that I put requests on from multiple different users, I'd probably want to pick the priority myself, but the backend/AFE may want to know and use the client's original priority.

[MikeBishop]

Right -- the header shows what the client originally wanted, and the frame shows what the peer on this hop wants; if those are different entities, it's better to keep them separate.

[martinthomson]

So it's nice that you have this clean conception of what intermediaries SHOULD do and how we can accommodate good practices. How does reality fit into this?

[kazuho]

@MikeBishop

Right -- the header shows what the client originally wanted, and the frame shows what the peer on this hop wants; if those are different entities, it's better to keep them separate.

I'm not sure if I agree with the characterization here. While it is true that headers are end-to-end, that does not necessarily mean that intermediaries should preserve those values when forwarding requests. An example here is caching proxies setting or changing the If-Modified-Since header when they translate a request to a conditional GET for a response that it has a cached copy.

I totally agree that if the intent is to send a hop-by-hop signal then it should send a PRIORITY_UPDATE frame.

But is there a reason to discourage intermediaries from sending an end-to-end signal?

Consider the case of an CDN that uses server-side knowledge to adjust client-driven priority. When forwarding a request for which the CDN has decided to change the priority, it would be make more sense to send a header-based signal, to make sure that hops near the origin would respect the adjusted value, regardless of the number of hops to the origin.

[ianswett]

In terms of what people do, I'm not sure we have quite enough experience to be sure.

Possibly we should soften the SHOULD and say that if the intermediary only intends to provide a prioritization signal for this connection, it SHOULD use PRIORITY_UPDATE because that preserves the client's original intent, and then explain the implications of intermediaries changing the value, and possibly why they might do so?

[kazuho]

I think that might be the correct thing to do. Filed #1735.

[MikeBishop]

So it's nice that you have this clean conception of what intermediaries SHOULD do and how we can accommodate good practices. How does reality fit into this?

I'm not sure which of us this was directed to, but I'll note that intermediaries are always capable of lying about the request the client made, or said more supportively, the request the intermediary makes is not always identical to the request from the client it's trying to fulfill. The only way to really keep intermediaries from doing that is signing with a key the intermediary doesn't have and enforcing the proper signature on the server. That seems like overkill, at least for this.

The reality is that intermediaries can misbehave and we have no power to stop them. But if they want to cooperate, we can and should provide guidance.