Open Bug 1415003 Opened 7 years ago Updated 2 years ago

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

Categories

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

Product:
Core
Component:
DOM: Service Workers
Type:
enhancement

Tracking

()

People

(Reporter: bkelly, Unassigned)

References

(Blocks 2 open bugs)

Details

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
Priority: -- → P2
Note, there is a spec PR to pass the priority internally as suggested in comment 0. See: https://github.com/whatwg/fetch/pull/785
Blocks: ServiceWorkers-compat
Flags: needinfo?(reyesalejandre)

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

Flags: needinfo?(reyesalejandre) → needinfo?(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.

Flags: needinfo?(annevk)

(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?

Flags: needinfo?(perry)

Andrew?

Flags: needinfo?(perry) → needinfo?(bugmail)

Updating the still valid ni?

Flags: needinfo?(bugmail)
Flags: needinfo?(bugmail)

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:
  • 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.
Flags: needinfo?(bugmail)

Is this somehow related to bug 1742596 comment 1 ?

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.