Bug 10409 - SVG fails due to gzip'd javascript
Summary: SVG fails due to gzip'd javascript
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P4 Normal
Assignee: Nobody
URL: http://www.carto.net/papers/svg/zueri...
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-15 01:08 PDT by Eric Seidel (no email)
Modified: 2010-07-08 01:16 PDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2006-08-15 01:08:06 PDT
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
Comment 1 Eric Seidel (no email) 2006-08-15 01:10:31 PDT
Here is another SVG which fails for the same reason:
http://www.carto.net/papers/svg/tuerlersee/
Comment 2 David Kilzer (:ddkilzer) 2006-08-15 03:23:29 PDT
(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?
Comment 3 Alexey Proskuryakov 2006-11-24 23:55:51 PST
This test doesn't work in Firefox either; the content type is definitely supposed to be text/javascript here.
Comment 4 Andreas Neumann 2006-11-25 07:06:15 PST
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
Comment 5 Alexey Proskuryakov 2006-11-25 09:12:20 PST
(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). 
Comment 6 Brent Fulgham 2009-08-26 10:23:31 PDT
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.
Comment 7 Brent Fulgham 2009-08-26 12:02:35 PDT
My mistake!  The SVG works correctly when gzipped, but the corresponding gzipped javascript fails silently.
Comment 8 Nikolas Zimmermann 2010-07-08 01:16:59 PDT
Changed component to SVG, so it shows up in my all-svg-bugs search.