Open mitar opened 4 years ago
As this would add quite a bit of complexity and also has novel same-origin policy implications I'm afraid this needs a stronger use case or demonstration of being a very widespread problem.
I guess what you really would want is in #607 (aka FetchObserver)
also has novel same-origin policy implications
Why? There is no change here, if you can access response and content-length
before, you could also now.
I guess what you really would want is in #607 (aka FetchObserver)
Interesting. That could also work, but it looks to me like even more work to get it in.
The same-origin policy also applies tor requests.
Yes, so? Can you elaborate a bit please what are "novel same-origin policy implications" you mean?
I looked at this again and you can already do this. If you set a Range
header the fetch algorithm will add this automatically as far as I can tell.
Hm, is this somewhere in the spec?
hmm, wanted to set the value to "identity" so i could get the final totalDownload for use in backgroundFetch.totalDownload, unfortunately it's also CORS, so not much control over that 😞
Currently, if I want to display a progress bar of how much data has been downloaded, I have to check
content-length
header to get the amount of all data so that I can correctly display the progress bar as I stream chunks of data into a JavaScript array. But the issue is that if server is usingcontent-encoding
set togzip
, thencontent-length
tells how large is compressed data, not uncompressed. But what I am getting in chunks in uncompressed. So there should be a way for me to get how large is uncompressed data.One way to achieve this is to do HEAD request with
accept-encoding
header set toidentity
. This would force the server to tell me the real size of the payload. But the issue is that currentlyaccept-encoding
header is not allowed to be set forfetch
requests. I would ask that an exception is made foridentity
.