On 10/31/11 11:34 AM, Boris Zbarsky wrote:
On 10/31/11 1:42 PM, Charles Pritchard wrote:
I'm almost certain that somewhere, it is specified that the browser
should sniff the first few bytes of the file to see
if it is compressed.
I don't believe it is. In fact, doing that would contradict the specs
as they stand, to my knowledge.
I could be wrong, of course, but in that case citation needed...
-Boris
Well I've failed to find a citation. I will post one if I find it.
In the meantime: Blob and Data uris can and should have sniffing for
image/svg+xml.
It's trivial, and it makes a whole lot more sense than extending both
the Blob and data uri specs to include transfer encoding semantics.
file: and filesystem: and widget urls are items that -might- be
supported on an OS level, and thus out of scope here.
Back to deflate use cases: PDF.js I'm sure implements deflate (for PDF
FlateEncode), I've recently done some docx work which required deflate.
Many servers do not host .svgz files well, and I use XHR with deflate to
deal with that (though I would have just used blob urls if they worked).
localStorage, indexedDB and WebSQL all require DOMString, as do most
WebSocket implementations -- in practical use, this means base64
encoding data. It's another area where deflate could squeeze a few more
bytes out of existing constraints. Especially with localStorage.
As we continue to support more-and-more document formats, deflate
support on the client side becomes more important. Apple and MS, two
very large vendors, have pushed ahead with using deflate in various file
formats they use. Adobe has been doing it for some time.
Though HTTP works quite well for negotiated compression there are more
and more cases that are not http bound. I would very much like to see
deflate and inflate exposed to the scripting environment. From there I
can easily interact with several file formats. Zip included.
-Charles
-Charles
