SETTINGS_HEADER_BASED_PRIORITY is not extensible

[ianswett]

I believe one benefit of using a header is that it's extensible. However, the current SETTINGS value can only be 0 or 1.

I think an approach where each peer sends all supported values makes the most sense? If the server only supports H2 frame priorities and doesn't support header prioritization, it seems like it'd be good to know that? Alternately, if there's a new extension to priorities(I keep bringing up 'ttl'), then one may want to use that in addition to 'urgency' and 'progressive'.

This is somewhat related to #26

[kazuho]

IMO, if we need a settings parameter to express the capability of endpoints depends on if the header field is going to be hop-by-hop. The answer would be yes if the header field (or the frame) is going to be hop-by-hop. OTOH, if the header field going to be end-to-end, settings parameters cannot be used as a reliable way of transmitting something. Rather, all the information should be transmitted using headers.

To rephrase, I tend to agree that SETTINGS_HEADER_BASED_PRIORITY is not designed well.

Assuming that we go with the end-to-end approach, I think what we really need is the SETTINGS_ENABLE_HTTP2_PRIORITIES SETTINGS parameter and a priority header field parameter that indicates downstream¹ nodes (not only the next hop but all the servers down to the origin) that the connection has been coalesced.

Consider the case where a browser sends a request with priority: urgency=3, progressive=?1. A proxy that coalesces the connections will be encouraged to set the coalesced parameter when forwarding the request downstream. So the header field that the proxy sends will be priority: urgency=3, progressive=?1, coalesced.

The takeaway here is that by using a header field, we can ensure that all the nodes downstream would understand that the connection has been coalesced and that the node should be careful when using the value of the header for prioritizing the hops it is taking care of.

[1] In HTTP, "stream" flows in the direction in which the HTTP messages are transferred. So for requests, the end client is the most upstream, and the origin server is the most downstream.

[rmarx]

I'm not sure I follow @kazuho's train of thought in response to Ian's description... the "coalesced" header field seems a bit perpendicular to indicating support for header-based prioritization? Or do you mean that if we do end-to-end headers, no explicit indication of support is needed (i.e., the sender can just set the headers without knowing if the receiver can use them?). I wouldn't agree with that statement, since then you would have to send headers and H2-style frames at the same time for H2, as you don't know if the headers are being used.

I am also in favor of a more general "SUPPORTED_PRIORITIZATION_SIGNALS" setting, that would be a list of signals/approaches supported (e.g., "dependency-tree", "urgency-progressive" (this draft), "ttl", "request-properties" (see #28), etc.). Those values are then defined in their own documents and are implicitly linked to a method (or multiple methods) of sending the signals. Since the whole idea of this redesign is to switch to signalling higher-level intent instead of low-level exact behavior, it would make sense to see that reflected in the "negotiation" as well.

[LPardue]

Agree that the negotiation in the priority header document has probably been overtaken by @bslassey design.

We can probably spin off the discussion around end-to-end and coalesced.

[kazuho]

@rmarx My point is that you cannot negotiate the use of an end-to-end header field using a SETTINGS value which is a per-hop mechanism.

A header field traverses through multiple hops. Some hops might use H1. One hop might support prioritization method A. Another hop might support prioritization method B.

I think HTTP generally handles this problem by suggesting the endpoints to send the signals for all the methods it supports, rather than trying to negotiate a particular method. For example, a server has been expected to send both Etag and Last-modified if it's interested in maximizing the chance of the client issuing a conditional request (Etag was added in HTTP/1.1 and is not supported by HTTP/1.0 clients).

[LPardue]

I don't think this is an issue that is still relevant but regardless, I believe the plan to go back to simpler scheme (#100) will address this issue. Therefore this should be resolved by the PR that resolves #100.

[ianswett]

Agreed, let's close this since #112 is about to land.