whatwg
data: URLs and Content-Length header
The current fetch spec says that all data: URL requests should result in a response with header list "Content-Type". https://fetch.spec.whatwg.org/#scheme-fetch
Nothing says about "Content-Length" header (blob: URLs is OK). Are there some side restrictions for add it?
Hmmm... but we already do it in https://fetch.spec.whatwg.org/#data-urls before send back response.
Exposing the length would impose requirements on when that algorithm is to be run relative to everything else, no?
I can't understand what this would impact. The "response" created from data: URLs is not really exposed, and is mostly a spec fiction.
And, Content-Length is ignored by browsers anyway.
It is exposed and while trying to demonstrate that to you, I found out that 2/3 browsers already expose Content-Length. Chromium doesn't. Hmm.
https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13841
Exposing the length would impose requirements on when that algorithm is to be run relative to everything else, no?
The decoding of the entire URL would impose requirements on the algorithm, but I asked this question because some major browsers already do parsing (decoding) and build response in one step but do not expose "Content-Length" header to response even have all required information (decoded buffer length).
Chromium: content/browser/data_url_loader_factory.cc Firefox: netwerk/protocol/data/nsDataChannel.cpp Servo: components/net/protocols/data.rs WebKit: Source/WebCore/loader/ResourceLoader.cpp
I do like to solve your problem According to the current Fetch specification (https://fetch.spec.whatwg.org/#scheme-fetch), data: URL requests are required to return a response with a "Content-Type" header, but there's no mention of a required or optional "Content-Length" header. This differs from blob: URLs, where a "Content-Length" may be more appropriate or expected.
Thanks!
