New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 620386 link

Starred by 4 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Oct 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Range header vanishing when passed to fetch()

Project Member Reported by jakearchibald@chromium.org, Jun 15 2016

Issue description

It seems like range headers added by <video> are lost when passed to fetch(). They're visible on the request object, but aren't sent to the server.

Firefox appears to do the same thing, so maybe this is a spec issue to do with headers and no-cors?

To recreate:

Clone, install & run
https://github.com/jakearchibald/range-request-test

Click "Register" to register SW.

Select respondWith(fetch(event.request))

Click "Exactly requested range"

See console, no range header is sent despite it existing in the request object passed to fetch.
 

Comment 1 by falken@chromium.org, Jun 16 2016

Components: Blink>Network>FetchAPI
Is it possible to reproduce this using just Request/fetch without SW?
Unfortunately not.

new Request('/test-vid.mp4', { mode: 'no-cors', headers: {'Range': 'bytes=0-'} });

The range header doesn't exist in the resulting request. I wonder if this is the source of the issue.

Do we need the concept of user-agent-added headers?
Creating a no-cors Request from nothing doesn't allow you to set non-simple requests. It's prevented by the request-no-cors guard set to the Headers object. But it shouldn't affect values already in the headers passed from the controlled page.
Status: Available (was: Untriaged)
Owner: eero.hak...@intel.com
Status: WontFix (was: Available)
The request-no-cors guard shouldn't affect values already in the headers passed from the controlled page. However, the request-no-cors guard does affect how fetch() processes the headers.

In the case of "fetch(event.request)":

The Fetch method (https://fetch.spec.whatwg.org/#dom-global-fetch) step 2 invokes the initial value of Request as constructor with input (event.request) and init as arguments.

The Request class constructor (https://fetch.spec.whatwg.org/#dom-request):
 * step 6.2 sets request to input's (event.request's) request
 * step 12 sets request to a new request whose mode is request's mode ("no-cors")
 * step 27 lets r be a new Request object associated with request and a new associated Headers object whose guard is "request"
 * step 28 lets headers be a copy of r's Headers object and its associated header list
 * step 30 empties r's Headers object's header list
 * step 31.3 sets r's Headers object's guard to "request-no-cors"
 * step 32 fills r's Headers object with headers

The Headers fill algorithm (https://fetch.spec.whatwg.org/#concept-headers-fill) appends for each header in headers header list, retaining order, header's name/header's value to r's Headers object.

The Headers append algorithm (https://fetch.spec.whatwg.org/#concept-headers-append) returns before appending name/value to header list if guard is "request-no-cors" and name/value is not a CORS-safelisted request-header (and Range is not such a request-header).

It is possible to pass the Range header using "fetch(event.request, { mode: "same-origin" })" instead of plain "fetch(event.request)" in which case the Request class constructor step 31.3 is not run.

It thus seems to me that Chrome is working according to the spec.

Sign in to add a comment