Re: [whatwg/fetch] Body's total bytes for HEAD requests (#284)

Discussed with @yutakahirano.

If it's well defined (e.g. what value `loaded` should be (0 or the same value as `total`)), it sounds not in-acceptable that we give `total` the role of telling the value in the Content-Length header of a response (more generally, the expected total length of the response body for various scheme, not only HTTP(S)) when the HEAD method is used, not the length of the actual response body (which expected to be non-existent (defined so at least for HTTP(S))).

That said, the main purpose of the ProgressEvent API is for tracking progress of loading the body of the response for non HEAD reqs. The above exception makes the API a bit complicated (a).

The only benefit is that users can use the unified way to probe the expected size leaving the protocol processing details (decoding decimal, understanding which meta deta is representing the expected body size) to the user-agent (b).

I think the question is which of (a) and (b) wins. I'm leaning toward (a), i.e. aligning Chrome to Firefox.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/284#issuecomment-219384762