Here is another SVG which fails for the same reason: http://www.carto.net/papers/svg/tuerlersee/

(In reply to comment #0) > curl -I "http://www.carto.net/papers/svg/zuerich_migration/scripts/main.es.gz" > HTTP/1.1 200 OK > Date: Tue, 15 Aug 2006 08:06:29 GMT > Server: Apache/2.0.54 (Linux/SUSE) > Last-Modified: Mon, 09 Aug 2004 15:34:37 GMT > ETag: "1cd80db-14d8-5abfbd40" > Accept-Ranges: bytes > Content-Length: 5336 > Content-Type: application/x-gzip > Content-Encoding: gzip > Content-Language: es Shouldn't the Content-Type be "text/javascript" with the Content-Encoding marked as "gzip" for this to work? Does it work in other browsers?

This test doesn't work in Firefox either; the content type is definitely supposed to be text/javascript here.

I wouldn't use this example as a testcase. It relies on getURL() for loading additional data and does not fork to the XMLHttpRequest alternative. It may also contains additional, non-standard code. From the examples at http://www.carto.net/papers/svg/samples/ I would only really test the ones marked to work with Op9+ - these are supposed to be standard conform. Some older examples linked at this pages, still need some renovation (I am working on that). However, gzipped Javascript is important, since often JS can get very large, esp. in mapping examples, where we sometimes store GIS attributes in Javascript. Thanks, Andreas

(In reply to comment #4) > However, gzipped Javascript is important, since often JS can get very large, Yes, compressed JavaScript should work with Safari, as long as compression is negotiated and used transparently (i.e., the encoding is one of those sent in Accept-Encoding header, and Content-Type of the answer matches the uncompressed content).

This bug appears to be resolved in current WebKit builds. Please reopen if this problem is still occurring, citing new test cases as the current test cases all pass.

My mistake! The SVG works correctly when gzipped, but the corresponding gzipped javascript fails silently.

Changed component to SVG, so it shows up in my all-svg-bugs search.

This file https://www.w3.org/2002/Talks/0328-Amsterdam-IH/directoryslide.svgz ``` HTTP/2 200 date: Thu, 22 Jan 2026 08:31:34 GMT content-type: image/svg+xml; qs=0.85 content-length: 5772 cf-ray: 9c1db21f7bca387b-NRT last-modified: Mon, 25 Mar 2002 11:05:23 GMT etag: "16bc-39d0169a3c2c0-gzip" cache-control: max-age=2592000 expires: Sat, 21 Feb 2026 08:31:34 GMT vary: Accept-Encoding content-encoding: gzip x-backend: www-mirrors x-request-id: 9c1db21f7bca387b strict-transport-security: max-age=15552000; includeSubdomains; preload content-security-policy: frame-ancestors 'self' https://cms.w3.org/ https://cms-dev.w3.org/; upgrade-insecure-requests cf-cache-status: BYPASS accept-ranges: bytes server: cloudflare alt-svc: h3=":443"; ma=86400 X-Firefox-Spdy: h2 ``` is not being processed by any browsers. Chrome, Firefox and Safari are not supporting this. Should we close?

Karl, your test has a different Content-Type header field.

The initial report gives an example of HTTP response for *something.gz* (which is different): Content-Type: application/x-gzip Content-Encoding: gzip I don't think this would be supported anywhere to display an SVG file. About .svgz specifically. There was an issue https://github.com/w3c/svgwg/issues/701 In the SVG2 spec it is said, explicitly https://svgwg.org/svg2-draft/single-page.html#conform-ConformingSVGServers > In addition, conforming SVG servers using HTTP > or other protocols that use Internet Media types > must serve SVG stand-alone files with the > media type "image/svg+xml". Then next paragraph. > Also, if the SVG file is compressed with gzip > or deflate, conforming SVG Servers must indicate > this with the appropriate header, according to > what the protocol supports. Specifically, for content > compressed by the server immediately prior to transfer, > the server must use the "Transfer-Encoding: gzip" > or "Transfer-Encoding: deflate" headers as appropriate. > For content stored in a compressed format on the server > (e.g. with the file extension .svgz), the server must use > the "Content-Encoding: gzip" or "Content-Encoding: deflate" > headers as appropriate. Summary 1. Simple SVG: Content-Type: image/svg+xml 2. SVG compressed on the fly by the server Content-Type: image/svg+xml Transfer-Encoding: gzip OR Content-Type: image/svg+xml Transfer-Encoding: deflate 3. SVG compressed manually and served as-is Content-Type: image/svg+xml Content-Encoding: gzip OR Content-Type: image/svg+xml Content-Encoding: deflate https://www.w3.org/2002/Talks/0328-Amsterdam-IH/directoryslide.svgz is using the recommended way of the spec. But no browsers seem to be supporting this at the moment. OR This specific svg file has an XML encoding error. OK next step I will setup a server locally with correct mime type to test and a correct svg and see if it's working as expected.