1654212 - Fetch Response Headers omits content-length

Status: RESOLVED DUPLICATE of bug 1460299

(Core :: DOM: Networking, defect)

Description

[guest271314]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

fetch('https://ia800301.us.archive.org/10/items/DELTAnine2013-12-11.WAV/Deltanine121113Pt3Wav.wav')
.then(response => console.log([...response.headers]))
.catch(console.error);

Actual results:

content-length is not included Response.headers.

Raw response headers

HTTP/1.1 200 OK
Server: nginx/1.16.1 (Ubuntu)
Date: Tue, 21 Jul 2020 08:05:05 GMT
Content-Type: audio/x-wav
Content-Length: 290689440
Last-Modified: Mon, 24 Feb 2014 01:27:11 GMT
Connection: keep-alive
ETag: "530a9fef-115391a0"
Strict-Transport-Security: max-age=15724800
Expires: Tue, 21 Jul 2020 14:05:05 GMT
Cache-Control: max-age=21600
Access-Control-Allow-Origin: *
Accept-Ranges: bytes

Expected results:

content-length should listed in Response.headers

Comment 1

[guest271314]

Per https://github.com/whatwg/fetch/issues/622 and https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name Content-Length is
a "CORS-safelisted response-header name"

A CORS-safelisted response-header name, given a CORS-exposed header-name list list, is a header name that is a byte-case-insensitive match for one of

-Cache-Control
-Content-Language
-Content-Length
-Content-Type
-Expires
-Last-Modified
-Pragma
Any value in list that is not a forbidden response-header name.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[Andy Grover [:grover]]

Hi Junior, can you help answer this CORS question?

Comment 4

[Junior [inactive]]

I believe this is an issue and it should be fixed. What do you think, anne?

Comment 5

[guest271314]

(In reply to Andy Grover [:grover] from comment #3)

Hi Junior, can you help answer this CORS question?

Are you sure this is a CORS issue?

If you navigate to https://developer.mozilla.org/en-US/ and run this code

fetch(location.href, {method:'head'})
.then(r => console.log(r.headers.get('content-length')))
// Promise { <state>: "pending" }
// null

is a CORS request being made?

Comment 6

[guest271314]

Attachment: Screenshot_2020-07-22_17-55-59.png

Comment 7

[guest271314]

For context arrived at this issue by attempting to create a SharedArrayBuffer using new WebAssembly.Memory({initial:<value>, maximum:<value>, shared: true}) where value is Response.headers.get('content-length') for the purpose of writing the data from the ReadableStream from Response.body to the SharedArrayBuffer during the read, for use in AudioWorkletProcessor while the request is ongoing, to stream audio without waiting for the entire request to complete, in the test case a 291 MB file is requested - which is served with Access-Control-Allow-Origin: * header https://github.com/guest271314/AudioWorkletStream/blob/shared-memory-audio-worklet-stream/index.html. The specification issue resolved the matter. In order to test the code at Nightly have to hardcode the Content-Length or set maximum to a value far greater than expected.

A potential workaround for that use case would be to dynamically grow() the buffer by 1 until the read is done, which ideally is what am trying to achieve, meaning we do not necessarily need to know the Content-Length of one or more requests in order to stream one or more files; that is instead of posting the TypedArray to the AudioWorkletProcessor, the SharedArrayBuffer is posted, and we read offsets using views to the underlying buffer with multiple, sequential, new TypedArrays without referencing the entire shared buffer. After preliminary testing am not there, yet, for dynamic memory growith and writing/reading without a single TypedArray, which this Mozilla bug might compel to experiment with sooner than later, yet the base case of using one TypedArray with length set to the Content-Length is currently impossible at Nightly 80.

Comment 8

[guest271314]

Am not the only individual that has noticed this

• “Content-Length” header not included in response from service worker fetch https://stackoverflow.com/q/56554878
• Firefox does not show the content-length header using getAllResponseHeaders https://stackoverflow.com/q/59053186

The specification issue was resolved in https://github.com/whatwg/fetch/issues/622.

Is this a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1460299 ?

Comment 9

[Junior [inactive]]

Is this a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1460299 ?

I believe it is, but I'll wait for anne to weigh in.

Comment 10

[Anne (:annevk)]

Yeah it is, it seems it even has a patch.