kazuho / draft-kazuho-httpbis-priority

Other
6 stars 4 forks source link

Priorities for PUSH #91

Closed rmarx closed 4 years ago

rmarx commented 4 years ago

During discussion in Singapore, the question was raised what the priority of PUSH streams is at the start. I don't think we specify this explicitly at this point (unless there is a "default" priority that would be used). Even then, it bears further contemplating what should happen...

Simply giving them a default would end them up competing with other stuff, so the default would have to be low. Other option would be to add a parameter to the header indicating "initial priority for the pushed 'children' of this request".

Probably some more nuances that I'm too sleep deprived to list right now. Either way, worth some discussion.

c-taylor commented 4 years ago

push is explicitly server defined as there is no client hint for that resource. Although there is no client hint, an origin hint may still be present.

Origin or intermediary (CDN) should honour origin described priority, as per rest of spec. As if the client had committed the (header|frame). Question is whether this requires explicit text...

If a client signal is not present, either through omission or because http-push... ... ...

@ianswett tells me that push reprioritisation is a slightly special case, and it sounds like that will need specific text.

kazuho commented 4 years ago

When push is used, both the request and response headers are created by the server. If either of the two contains a priority header field, the value of that header field should be used.

The question is what to do when there is no hint.

I think we might want to start by saying that a pushed request inherits the urgency of the request that initiated the push, with progressive set to ?0. This mimics the definition of the tree-based prioritization scheme of HTTP/2, and therefore be least surprising.

If people are unhappy with that, then we can discuss.

LPardue commented 4 years ago

I agree push request should inherit the request's priority. It should pass this on to the next hop (whether that is just an internal API or an origin). This creates a consistent approach for processing request prioritisiation and allows the server to simply consider the final collaborated version of the priority when deciding how to prioritise delivery of response data.

LPardue commented 4 years ago

Lets continue the conversation at https://github.com/httpwg/http-extensions/issues/1056