XMLHttpRequest HEAD request total 0

RESOLVED INVALID

Status

()

Core
DOM
RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: shaharmor1, Unassigned)

Tracking

({testcase})

48 Branch
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: btpp-followup-2016-04-26)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36

Steps to reproduce:


var xhr = new XMLHttpRequest();
xhr.responseType = 'arraybuffer';
xhr.open('HEAD','https://betamg-i.akamaihd.net/hls/live/231610/coral/playlist.m3u8');
xhr.onload = function(e) {
    console.log('total:', e.lengthComputable);
    console.log('total:', e.total);
};
xhr.send();


Actual results:

e.total is 0


Expected results:

e.total should equal the content length of the resource

Updated

2 years ago
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM
Ever confirmed: true
Keywords: testcase
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
(Reporter)

Comment 1

2 years ago
The URL here might not be available, you can use this one for example: https://storage.googleapis.com/livestream/hls/video/surf-drone/segment-17.ts
Anne, is Gecko behaving incorrectly here?
Flags: needinfo?(annevk)
Whiteboard: btpp-followup-2016-04-20

Comment 3

2 years ago
No Gecko is correct. No body bytes are transferred after all.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(annevk)
Resolution: --- → INVALID
(Reporter)

Comment 4

2 years ago
Hey Anne,
Thanks for the quick reply.

The specification is saying that the total field should equal the size of the entity-body, which is described as:

"If the length of the HTTP entity body is known through the Content-Length header, initialize the lengthComputable attribute to true and initialize the total attribute to the length."

It is also mentioning the following:

"The Content-Length entity-header field indicates the size of the
 entity-body, in decimal number of OCTETs, sent to the recipient or,
 in the case of the HEAD method, the size of the entity-body that
 would have been sent had the request been a GET."

So in a HEAD request, it should equal the size that would have been fetch if the request was a GET, which is exactly my issue.
(Reporter)

Updated

2 years ago
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Comment 5

2 years ago
You might be reading an out-of-date specification. I suggest contacting the organization responsible for publishing it. This is defined in https://xhr.spec.whatwg.org/ and https://fetch.spec.whatwg.org/ these days.
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → INVALID
(Reporter)

Comment 6

2 years ago
Forgot to mention, but this issue is happening only on Firefox.

On Chrome/Opera/IE is it indeed setting the "total" field to the length of the request would have been if it was a GET (Which is basically the Content-Length header)
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Comment 7

2 years ago
My, I think you are correct and I think the specification even agrees, though I filed https://github.com/whatwg/fetch/issues/284 just in case (and will use that issue to specifically mention this situation if this is indeed the way we want to go).
Status: REOPENED → NEW
Whiteboard: btpp-followup-2016-04-20 → btpp-followup-2016-04-26

Comment 8

2 years ago
Anne, am I reading your link in comment 7 correctly and Firefox's behavior was chosen as "correct" (in which case this bug can be closed)? Or does this issue still need further discussion on the spec side?
Flags: needinfo?(annevk)

Comment 9

2 years ago
Engineers from Chrome want to align with the standard, that's probably good enough for us indeed.
Status: NEW → RESOLVED
Last Resolved: 2 years ago2 years ago
Flags: needinfo?(annevk)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.