RE: Whats the status on .svgz support from file://

Thanks Amelia, sloppy on my part.. should have been this list.

I don’t know how the browsers handle what comes from file systems, but MIME types would not be something they care about from what I recall, they just provide access to data streams.  I suspect, if anything, the browser internally would try and inject a MIME type when resolving a file:// URL.

The cross OS problem of do you require extensions (.svg vs .svgz a windows type solution) or magic cookie (unix type solution) to determine how to handle a file exists.  But as the browsers (IE11 & Firefox ESR 45.4.0 I’m looking at you ) supposedly already have the decompressing solution to support the http:// URL, it would not be difficult to get things to work for file://  I would think.

And yes, those browsers are OLD by browser maker standards, but we inside large corporate land don’t get to just deploy the latest builds of a browser, we have to make solutions that work across a massive enterprise that’s all synced to a corporate standard. ;-) .  We will have hundreds of thousands of SVG technical graphics, and them taking up an order of magnitude less space would be nice.

I’ll look at putting in an issue to make it clearer that compressed (.svgz) must also be supported under file:// to be a complying viewer.

Thomas
--
Thomas Smailus, Ph.D.  P.E.
Boeing Information Technology
thomas.o.smailus@boeing.com

From: Amelia Bellamy-Royds [mailto:amelia.bellamy.royds@gmail.com]
Sent: Wednesday, October 26, 2016 11:50
To: Smailus, Thomas O <Thomas.O.Smailus@boeing.com>; www-svg <www-svg@w3.org>
Subject: Re: Whats the status on .svgz support from file://

(Moving this to the main list, since it's a substantive issue, not a working group administrative issue)

On 26 October 2016 at 11:47, Smailus, Thomas O <Thomas.O.Smailus@boeing.com<mailto:Thomas.O.Smailus@boeing.com>> wrote:
I’m curious where things stand with SVG 2 on svgz support with respect to reading an SVG document form file://
The server is the file system.  Does a conforming SVG Interpreter need to support SVG content encoded in the svgz compression format?

Thomas

I did the update & re-write of the conformance section. I was trying not to make any unintentional changes, and I didn't think about this particular question, so I also didn't add any clarifications for it.

For reference, here's SVG 1.1: https://www.w3.org/TR/SVG11/conform.html

And here's SVG 2: https://www.w3.org/TR/SVG2/conform.html#SoftwareConformanceClasses


Both state in the bullet list of requirements for Conforming SVG Viewers:

·         SVG implementations must correctly support gzip-encoded<http://www.ietf.org/rfc/rfc1952.txt> [rfc1952<https://www.w3.org/TR/SVG2/refs.html#ref-rfc1952>] and deflate-encoded<http://www.ietf.org/rfc/rfc1951.txt> [rfc1951<https://www.w3.org/TR/SVG2/refs.html#ref-rfc1951>] data streams, for any content type (including SVG, script files, images). SVG implementations that support HTTP must support these encodings according to the HTTP 1.1<http://www.ietf.org/rfc/rfc2616.txt> specification [rfc2616<https://www.w3.org/TR/SVG2/refs.html#ref-rfc2616>]; in particular, the client must specify with an "Accept-Encoding:" request header [HTTP-ACCEPT-ENCODING<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3>] those encodings that it accepts, including at minimum gzip and deflate, and then decompress any gzip-encoded<http://www.ietf.org/rfc/rfc1952.txt> and deflate-encoded<http://www.ietf.org/rfc/rfc1951.txt> data streams that are downloaded from the server. When an SVG viewer retrieves compressed content (e.g., an .svgz file) over HTTP, if the "Content-Encoding" and "Transfer-Encoding" response headers are missing or specify a value that does not match the compression method that has been applied to the content, then the SVG viewer must not render the content and must treat the document as being in error<https://www.w3.org/TR/SVG2/implnote.html#ErrorProcessing>.
If you take out the parts about HTTP, you still have a requirement for all conforming SVG viewers to support GZip-encoded content, which for file system access would primarily be about .svgz.

In addition, as you point out, the operating system file server and the browser's file: protocol together count as a SVG Server. To be conforming, the should therefore properly identify .svgz files as SVG mime type to browsers accessing local files. I'm not sure whether the OS file systems declare MIME types in other software contexts, but if so the same rule would apply.

If you have suggestions for clarifications, or concerns about this requirement, open an issue on https://github.com/w3c/svgwg/issues.


This entire section was much neglected in the editing process, because it was tucked away in an appendix in SVG 1.1, even though it was marked as normative requirements.  I updated it wherever we had conflicting requirements elsewhere, or where referenced specs were out of date, but I didn't change most of these specific details.

~Amelia