SVG fails due to gzip'd javascript http://www.carto.net/papers/svg/zuerich_migration/index.svgz I'm not sure if we're supposed to support this or not. Hyatt or Maciej might know. 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
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.