Priorities should affect request behavior as well as response behavior

[ianswett]

Currently, there's no discussion of whether the priority header affects request behavior as well as response behavior. I believe it should affect both whenever possible and that should be specified.

In some cases, that could be a browser delaying sending lower priority requests behind higher priority ones, and in others(ie: a large POST) that could be changing the congestion control characteristics to ensure the request would not significantly impact other requests.

[kazuho]

👍

[rmarx]

+1

[LPardue]

The title "The Priority HTTP header field" makes these discussions hard because I'm not sure sure if @ianswett is talking about abstract absolute priority levels or concrete signal in the form of HTTP headers or frames. I think we should try to tackle terms in the next document update.

I don't understand how a priority header can affect the scheduling of requests inside the user agent. However, the abstract concept herein is that the UA generates the priority signal based on its local usage of the resource. So it is fully in the means of UAs to modulate their behaviour (ordering, or send rate) based on usage. Is that what is being proposed on this ticket?

The actual recommended behaviour is likely to depend on the connection prioritization scheme. For example, signalling lower priorities later might work well for FIFO but would perform poorly for LIFO. How specific is the guidance that we are attempting to capture?

[rmarx]

In my view, this is mostly for when developers are setting the priority themselves (e.g., indirectly using an HTML tag attribute or directly via fetch()). As we mentioned in the previous meeting, if "headers are the API" (much like how the preload header triggers push), then priority headers set by the developer on the client side (e.g., via JS) can/should trigger browser behavior changes.

As Ian indicates, a developer performing a large background POST (e.g., from a service worker) could indicate this using priority headers, triggering appropriate browser-side behavior. I would see this as an option to impact HTTP/1.1 as well, where some requests can be delayed (not taking up 1 of the 6 allowed connections) if they are low priority.

Granted, the benefits are not huge in my opinion, but enough to specifically adopt this use case (it's also nice and symmetrical ;))

[LPardue]

As mentioned elsewhere, I'd like us to document use cases and actors so we can be clear in our communications.

I'm not disputing some of the benefits but there are different system boundaries and relationships inside the UA - which the HTTP header document was not not geared up to handle and the IETF WG are perhaps not best placed to argue for or against. For instance, we are debating adding more dimensions and more levels of granularity, while the Priority Hints proposal has settled on 2 levels.

Preload is a fantastic example of a header that means different things to different actors in the chain of a response - as such the community hits issues like this, where something safe in a server could be unsafe in a UA if used a certain way. It requires analysis and deep thought, adding friction. If we want to make a more extensible framework for prioritization, we should be mindful to such considerations.

[rmarx]

1. My attempt at starting a list of such use cases and actors is at : https://groups.google.com/forum/#!topic/http-priorities-design-team/CchOCEYJUgI. One of the "undecided" items is the JS integration, which imo this partains to.

2. I'm not sure what this specific issue has to do with adding more dimensions... if you're going to do this header-based, it's going to be available to JS fetch no matter what? This issue is about whether the browser should be reading those headers and do something with them client side or not. If you don't want developers to have access to low-level stuff, then either we need to drop the header-based design, or make sure browsers disallow developers from setting the header themselves, which I would find a bad idea. For me, this issue is mainly the difference between "clients MAY act upon the signals" vs "clients MUST NOT/SHOULD NOT act upon the signals".

3. I do think we need to take care and take into account these different aspects, but that's not different then/part of/similar to the end-to-end vs hop-to-hop discussion for me.

[LPardue]

The simplest case where things get confusing are, taking Ian's example, making a POST Fetch request with a `Priority :urgency=background" header. If that is intended to control the UA's behaviour and/or the behaviour of the remote endpoint (proxy or server) sending the response. Should a UA consume such a header and repopulate it before transmission?

I'm not sure what this specific issue has to do with adding more dimensions

This is about the API surface exposed to web developers that allows them to control the user agent behaviour. The more options and parameters that we add, the harder it becomes for any developer to understand what the effect is. And since we are talking about using a header to control the behaviour of a user agent, I would presume the expectation is that it is exhaustively documented in a body such as W3C or WHATWG. Note that there is major overlap with the problem space of Priority Hints - its just that the solution is different.

I'd also be concerned with web devs attempting to optimise priority when they don't have a good picture of the connection attributes of site in question.

If you're going to do this header-based, it's going to be available to JS fetch no matter what?

The Fetch spec defines multiple levels of headers:

• CORS non-wildcard request-header name
  • Authorization
• Privileged no-CORS request-header name
  • Range
• CORS-safelisted response-header name
  • Cache-Control
  • Content-Language
  • Content-Length
  • Content-Type
  • Expires
  • Last-Modified
  • Pragma
  • Any value that is not a forbidden-response-header name
• no-CORS-safelisted request-header name
  • Accept
  • Accept-Language
  • Conent-Language
  • Content-Type
• forbidden header name
  • Accept-Charset
  • Accept-Encoding
  • Access-Control-Request-Headers
  • Access-Control-Request-Method
  • Connection
  • Content-Length
  • Cookie
  • Cookie2
  • Date
  • DNT
  • Expect
  • Host
  • Keep-Alive
  • Origin
  • Referer
  • TE
  • Trailer
  • Transfer-Encoding
  • Upgrade
  • Via
  • or any name that starts with "Proxy-" or "Sec-"
• forbidden response-header name
  • Set-Cookie
  • Set-Cookie2

Forbidden header names are a category "so the user agent remains in full control over them.". Are we qualified to determine which of these lists Priority would belong to?

Perhaps we would be better defining a mixin (or extension to the Body mixin) that can express the priority of a request & body.

[ianswett]

I was thinking of use cases like POST via fetch when I wrote this up, but I also had in mind cases when a browser or app sends a background priority request and it may want to delay that when there are a large number of other outstanding requests.

I agree that clarifying terminology would be useful and I wonder if creating separate sections for some of these concepts in the draft would help?

One way of splitting them would be:

1. What is the priority functionality, what does it mean? Use cases(or maybe that's its own section)
2. How to convey this in an HTTP header.
3. How to convey this in an H2 or H3 frame.

[LPardue]

See 3-year old open issue on Fetch

whatwg/fetch#436

Currently the browser makes a number of decisions about what network requests are high priority vs low priority. We could expose this as a Request.priority attribute.

In addition, we could allow script to set this so that authors can hint that some requests are low priority. For example, think of a requestIdleCallback() that is intended to avoid interfering with normal page operation, but it needs a network request. It could use a "low" priority.

Another use case would be pre-caching resources at a low priority in a ServiceWorker's install event handler. This would reduce any impact to the currently displayed page.

I don't think we would want to guarantee honoring the value, though. It would be a hint and best effort by the browser.

[LPardue]

Also related issue in HTML whatwg/html#3670

[kazuho]

I wanted to revisit this issue and suddenly realize that we might have crossed the river by merging #54. The abstract now talks about prioritizing "the delivery of HTTP responses," rather than the transmission. It is now possible to argue that prioritizing the delivery includes the order in which the requests are processed. I hope @LPardue would be OK with that.

I also think that "delivery of response" might be a better way of phrasing the scope rather than discussing "prioritization of request and responses," as processing order of requests is something that's internal to the server. That's not something that a network protocol needs to talk about.

@LPardue Does my comment here ease the concerns you have? If that is the case, I can create a PR that changes the tone of the document to talk more about delivery rather than transmission. I could also try to suggest (maybe a little bit) that the server can control the processing order of the requests to improve the delivery order.

[ianswett]

#54 didn't really change that part of the abstract, so I think it was a good change.

I'd suggest removing "the delivery of" because it's a bit overly restrictive and I don't think it is helpful to the doc.

In my mind, prioritization is very much about intent, so a server can use that information to do whatever it can to try to honor the intent, which could involve re-ordering the processing, sending to backends, delivery, etc.

[kazuho]

@ianswett Actually, we used to talk about specifying "the absolute precedence of an HTTP response," but PR 54 changed that to "prioritizing the delivery of HTTP responses."

In my mind, prioritization is very much about intent, so a server can use that information to do whatever it can to try to honor the intent, which could involve re-ordering the processing, sending to backends, delivery, etc.

Makes perfect sense. I now agree with you that it is best to talk about "prioritizing HTTP responses" rather than "prioritizing XXX of HTTP responses," regardless of what XXX is.

At the moment, we do have sentences like "A server SHOULD transmit HTTP responses in the order of ..." I'll try to change those to not talk about transmission, etc.

[LPardue]

Agree with removing XXX. However, preserving use of transmission aligns us with H2's priority scheme which discussed it in those terms, from RFC 7540

The purpose of prioritization is to allow an endpoint to express how
it would prefer its peer to allocate resources when managing
concurrent streams. Most importantly, priority can be used to select
streams for transmitting frames when there is limited capacity for
sending.

And now that its been highlighted, I really don't like the term delivery. From an application perspective there is very little I can do to affect the way things are delivered. And very little the receiver of the delivery can do to validate I acted as it requested.

But to get back on topic, I think the present design of Priority header is applicable only to responses . If we truly want to tackle prioritisation of requests, which is not required to get feature parity with HTTP/2, then I'm probably in agreement with my perception of what @mnot said in Cupertino, that it needs to be a distinct header - and more work is required to avoid just handwaving this area.

[kazuho]

Removed "delivery," as we seem to agree that it's bad.

[kazuho]

But to get back on topic, I think the present design of Priority header is applicable only to responses . If we truly want to tackle prioritisation of requests, which is not required to get feature parity with HTTP/2, then I'm probably in agreement with my perception of what @mnot said in Cupertino, that it needs to be a distinct header - and more work is required to avoid just handwaving this area.

Let's assume that the transaction of a HTTP request-response can be divided into three elements: transmission of a request, processing of a request, transmission of a response.

The scope of the draft definitely includes how the response is being transmitted. I am fine with keeping the transmission of requests out-of-scope, as I can see the concern regarding the schedule. OTOH, I do have a preference on including the processing of a request within the scope of the draft.

The reason I want to suggest in the draft that the prioritization scheme can affect the processing order of the requests within the server is because it has benefits.

In certain cases, a server does not have the enough internal concurrency to process all the request it receives from the client. For example, maximum number of FastCGI server processes that can be run in parallel is typically much smaller than the maximum number of concurrent requests that a HTTP/2 server can accept. When the H2 server hits the maximum concurrency of the FastCGI server processes, it needs to queue the requests and issue them in certain order. For that purpose, the value of the priority header is really handy.

I'd argue that suggesting using the values of the priority header for this particular purpose is completely fine, as it is something internal to a server. It's not something a protocol specification needs to interfere.

@LPardue Would you be fine with me talking about that in the I-D?

[LPardue]

I'm coming to the conclusion that the ticket is conflating different aspects.
I agree there is value in using any and all information available. I'm happy to review some text in the I-D for the thing you mention, although I might err on it being as light as possible.

My objections are:

• problems we might incur if the request processing element is also applicable to the web platform APIs .
• confusion around the proposal to recommend request priority affect transport-level properties such as flow control. For example, if a client makes a POST request with urgency = 6 (background) are they asking to have low priority on the upload or the download?

I could imagine that it would be helpful to have split-mode priorities that allow a client to express upload and download independently. For example, informing a server that data sample uploads to a server are very important, but the responses are much less important.

[ianswett]

For most practical use cases I can think of, I'm not sure the extra richness of a separate upload and download priority is worthwhile. In your example, the upload is important, but the response is probably tiny, so why not send it quickly?

I think about each HTTP request as a transaction. Priorities are a way of saying "I'd like this transaction to complete before that one, assuming they're competing for resources at some level." In that sense, I think any layer using the information is within scope. On the other hand, I don't think we should add a MUST that every possible layer use the information, because that seems overly proscriptive and possibly impractical.