1121157 - Fetch API: Add tests to check request's context on intercepted requests.

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

Requests sent via fetch events to a ServiceWorker should have the correct context set on them. It is impossible to test this until Bug 1065216 and Bug 1113555 have landed, so wait on them.

Comment 1

[(no longer active)]

Why does Request.context reflect Request::mContext, and not InternalRequest::mContentPolicyType?  It seems that the Request objects intercepted in FetchEvent should always have the wrong context attribute because of this (unless the request is coming from fetch).

Comment 2

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

We don't have code that maps from the channel's policy type + originating node and other factors to a valid context and context frame type as specified in the fetch spec. In addition our nsIContentPolicyType does not map onto the full set of contexts specified in the spec. Yes, by default Requests intercepted by SW will have context 'fetch' even if they don't come from fetch. A minimum fix would be to have FetchEventRunnable::Init() at least set the correct type on the InternalRequest as grabbed from the channel. The spec fix so that JS observes the right context needs someone to put in the work to come up with this mapping, including being aware of any subtleties.