1415003 - pass through SW should propagate outer network channel priority to the fetch() channel

Status: NEW

(Core :: DOM: Service Workers, enhancement, P2)

Description

[Ben Kelly [:bkelly, not reviewing]]

Currently nsIChannels get a certain priority level based on what part of the page load created it (img vs script, etc).  We should pass this priority value through in a pass-through service worker fetch().

There is an open spec issue to expose this on FetchEvent.Request.priority, but in the meantime we can implement it as a hidden internal value that gets passed through.

https://github.com/whatwg/fetch/issues/436

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Note, there is a spec PR to pass the priority internally as suggested in comment 0.  See:

https://github.com/whatwg/fetch/pull/785

Comment 2

[Jens Stutte [:jstutte]]

Hi Anne, can you please check if this is still wanted?

Comment 3

[Anne (:annevk)]

This never got publicly exposed, but there is an internal priority value that needs propagation. If we're not doing that, then this is still a valid bug.

Comment 4

[Jens Stutte [:jstutte]]

(In reply to Anne (:annevk) from comment #3)

This never got publicly exposed, but there is an internal priority value that needs propagation. If we're not doing that, then this is still a valid bug.

Perry, are we doing this?

Comment 5

[Jens Stutte [:jstutte]]

Andrew?

Comment 6

[Jens Stutte [:jstutte]]

Updating the still valid ni?

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

Still valid, not implemented.

Restating:

• This is about the situation where we fetchEvent.respondWith(fetch(fetchEvent.request)) and we want to make sure the priority of the FetchEvent request that is set onto the InterceptedHttpChannel is:
  • Propagated into the IPCInternalRequest representation of the intercepted request. This starts in SendFetchEvent in GetIPCInternalRequest.
  • Processed by FetchDriver::HttpFetch when translating the mRequest into HTTP channel requests.
    • FetchService will also (currently) use this path.
• The only field we tunnel that is related to priority right now is our nsContentPolicyType mapping which corresponds to the fetch destination.
• Judging from the recently fixed bug 1730852 (which was about nsIClassOfService information not being propagated onto InterceptedHttpChannel because of QI failures), we will also want to:
  • Check that InterceptedHttpChannel is properly QI-ing to nsISupportsPriority
  • Potentially include both the nsIClassOfService and nsISupportsPriority fields as (internal) fields on (IPC)InternalRequest.
• This is not about the Response that the promise returned by the pass-through fetch call will return. Just about the Request that gets passed to the fetch call.

Comment 8

[Jens Stutte [:jstutte]]

Is this somehow related to bug 1742596 comment 1 ?