4648 2005-08-25 02:25:39 -0700 Shockwave unable to load GZip'd text resources when server sends Content-Length header 2007-08-16 05:38:14 -0700 1 1 1 Unclassified WebKit Plug-ins 420+ Mac OS X 10.4 RESOLVED FIXED http://www.kotska.com/swtest/ InRadar P2 Normal --- 1 sulka webkit-unassigned ap oldest_to_newest 17406 0 sulka 2005-08-25 02:25:39 -0700 When a Shockwave movie loads an external text resource over HTTP and the delivery uses the gzip content-encoding, and the server sends the resource with the Content-Length header set, the download always fails for some reason. If the server doesn't send the Content-Length header and specifies "Transfer-Encoding: chunked", the download succeeds. Safari seems to misreport the file size to the plugin in the case of failure - for some reason the file size is reported as being larger than the gzipped version (correct) but smaller than the decompressed resource so it seems that if the plugin asks for details of the file while the file is being decompressed, the decompression is somehow interrupted and the length of the already decompressed content is reported. Clearly there's some functional difference in how the content is delivered to plugins depending on the encoding type. Reproducible: Always Steps to Reproduce: See http://www.kotska.com/swtest/ for a testcase. Actual Results: The file being downloaded is downloaded but never delivered to the plugin. Expected Results: File should have been passed onto the plugin. 17911 1 sulka 2005-08-30 03:41:34 -0700 Tried this using both Safari 2.0.1 and the latest CVS version (AppleWebKit/420+ Safari/412.5) and the test fails using both. Effectively this means any site using Shockwave has to disable gzip compression for compatibility with Safari, causing textual content to require roughly 8-10x the amount of bandwidth necessary with compression. 18988 2 oliver 2005-09-07 04:25:37 -0700 Good test case 35044 3 aldo 2006-03-04 05:40:49 -0800 The testcase fails the same way in Firefox (1.0 and 1.5), both on OS X and Windows. 35367 4 sulka 2006-03-07 02:10:58 -0800 The Firefox bug is reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=305766 FYI: Internet Explorer (Mac and Windows) doesn't fail the test and since the plugin running within those browsers is (afaik) exactly the same code on a given platform, there has to be some differences in the browser implementation. We have 100k+ Mac users on our site every month and as a result of this bug, most of these users have to download about 300kB of extra unnecessarily uncompressed data on every visit. 35444 5 6922 ap 2006-03-07 11:50:44 -0800 Created attachment 6922 proposed fix Can we make automated tests for such bugs? 35483 6 6922 darin 2006-03-07 20:56:07 -0800 Comment on attachment 6922 proposed fix This patch is not quite right. The content encoding might be "identity", so just the presence of a content encoding header field is not the correct check. Also, buggy servers sometimes send strings like "identity, identity". It's hard to code this correctly at the WebKit level and stay in sync. with the features of the NSURL level; ideally we would have a Foundation method like expectedContentLength, but one that knew to only give us the length for things it won't decode. In general we don't want code that has to second-guess what NSURL is doing for us. Current versions of NSURLConnection support "deflate" and "gzip"; anything else is treated as "identity". The comparison is done in a case insensitive manner. NSURLConnection knows how to parse off an optional "x-" prefix. It knows how to ignore parameters that come after an optional ";" separator. It knows how to ignore whitespace. It parses a list separated by commas; if all the items in the list are the same (ignoring case, whitespace, "x-" prefixes, and parameters) then it uses it, otherwise it treats it as "identity". Hard-coding this precise rule into WebBaseNetscapePluginStream would be kinda lame, but I don't have a better idea. 35497 7 ap 2006-03-08 00:49:20 -0800 <rdar://4470599> for NSURLConnection. 35887 8 ap 2006-03-11 04:36:25 -0800 Actually, I think that expectedContentLength itself should only give us the length for things it won't decode, so I'm going to just wait for the resolution of the above Radar. That said, I still don't really understand why a simplified rule like the one used in the patch is much worse for deciding what to pass to the plugin. Also, servers SHOULD NOT send Content-Encoding: identity, according to RFC2616. 2456 9 15938 ap 2007-08-12 03:21:47 -0700 Created attachment 15938 updated fix As mentioned above, I think we do not need to match NSURLConnection logic particularly well. 2463 10 15938 darin 2007-08-12 12:05:47 -0700 Comment on attachment 15938 updated fix OK, at this point it seems smart to work around the NSURL bug. r=me 2466 11 ap 2007-08-12 12:26:02 -0700 Committed revision 25024. 2189 12 mrowe 2007-08-16 05:38:10 -0700 <rdar://problem/5415340> 6922 2006-03-07 11:50:44 -0800 2007-08-12 03:21:47 -0700 proposed fix 4648r1_patch.txt text/plain 1130 ap SW5kZXg6IFdlYktpdC9QbHVnaW5zL1dlYkJhc2VOZXRzY2FwZVBsdWdpblN0cmVhbS5tCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIFdlYktpdC9QbHVnaW5zL1dlYkJhc2VOZXRzY2FwZVBsdWdpblN0cmVhbS5tCShy ZXZpc2lvbiAxMzE4MykKKysrIFdlYktpdC9QbHVnaW5zL1dlYkJhc2VOZXRzY2FwZVBsdWdpblN0 cmVhbS5tCSh3b3JraW5nIGNvcHkpCkBAIC0yNTMsOCArMjUzLDE2IEBAIHN0YXRpYyBjb25zdCBj aGFyICpDYXJib25QYXRoRnJvbVBPU0lYUGEKIAogLSAodm9pZClzdGFydFN0cmVhbVdpdGhSZXNw b25zZTooTlNVUkxSZXNwb25zZSAqKXIKIHsKKyAgICAvLyBJZiB0aGUgY29udGVudCBpcyBlbmNv ZGVkIChtb3N0IGxpa2VseSBjb21wcmVzc2VkKSwgdGhlbiBkb24ndCBzZW5kIGl0cyBsZW5ndGgg dG8gdGhlIHBsdWdpbiwKKyAgICAvLyB3aGljaCBpcyBvbmx5IGludGVyZXN0ZWQgaW4gdGhlIGRl Y29kZWQgbGVuZ3RoLCBub3QgeWV0IGtub3duIGF0IHRoZSBtb21lbnQuCisgICAgbG9uZyBsb25n IGV4cGVjdGVkQ29udGVudExlbmd0aCA9IC0xOworICAgIGlmIChbciBpc0tpbmRPZkNsYXNzOltO U0hUVFBVUkxSZXNwb25zZSBjbGFzc11dICYmCisgICAgICAgIG5pbCA9PSBbWyhOU0hUVFBVUkxS ZXNwb25zZSAqKXIgYWxsSGVhZGVyRmllbGRzXSAKKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICBvYmplY3RGb3JLZXk6QCJDb250ZW50LUVuY29kaW5nIl0pCisgICAgICAgIGV4cGVjdGVkQ29u dGVudExlbmd0aCA9IFtyIGV4cGVjdGVkQ29udGVudExlbmd0aF07CisgICAgICAgIAogICAgIFtz ZWxmIHN0YXJ0U3RyZWFtUmVzcG9uc2VVUkw6W3IgVVJMXQotICAgICAgICAgICBleHBlY3RlZENv bnRlbnRMZW5ndGg6W3IgZXhwZWN0ZWRDb250ZW50TGVuZ3RoXQorICAgICAgICAgICBleHBlY3Rl ZENvbnRlbnRMZW5ndGg6ZXhwZWN0ZWRDb250ZW50TGVuZ3RoCiAgICAgICAgICAgICAgICAgbGFz dE1vZGlmaWVkRGF0ZTpXS0dldE5TVVJMUmVzcG9uc2VMYXN0TW9kaWZpZWREYXRlKHIpCiAgICAg ICAgICAgICAgICAgICAgICAgICBNSU1FVHlwZTpbciBNSU1FVHlwZV1dOwogfQo= 15938 2007-08-12 03:21:47 -0700 2007-08-12 12:05:47 -0700 updated fix 4648r2_patch.txt text/plain 2451 ap SW5kZXg6IFdlYktpdC9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViS2l0L0NoYW5nZUxvZwko cmV2aXNpb24gMjUwMTYpCisrKyBXZWJLaXQvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBAIC0x LDMgKzEsMTQgQEAKKzIwMDctMDgtMTIgIEFsZXhleSBQcm9za3VyeWFrb3YgIDxhcEB3ZWJraXQu b3JnPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIGh0 dHA6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTQ2NDgKKyAgICAgICAgU2hvY2t3 YXZlIHVuYWJsZSB0byBsb2FkIEdaaXAnZCB0ZXh0IHJlc291cmNlcyB3aGVuIHNlcnZlciBzZW5k cyBDb250ZW50LUxlbmd0aCBoZWFkZXIKKworICAgICAgICAqIFBsdWdpbnMvV2ViQmFzZU5ldHNj YXBlUGx1Z2luU3RyZWFtLm1tOgorICAgICAgICAoLVtXZWJCYXNlTmV0c2NhcGVQbHVnaW5TdHJl YW0gc3RhcnRTdHJlYW1XaXRoUmVzcG9uc2U6XSk6IERvbid0IHRydXN0IAorICAgICAgICAtW05T VVJMUmVzcG9uc2UgZXhwZWN0ZWRDb250ZW50TGVuZ3RoXSBpcyBDb250ZW50LUVuY29kaW5nIGlz IG5vdCBpZGVudGl0eS4KKwogMjAwNy0wOC0xMCAgVGltb3RoeSBIYXRjaGVyICA8dGltb3RoeUBh cHBsZS5jb20+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkgTWFyayBSb3dlLgpJbmRleDogV2ViS2l0 L1BsdWdpbnMvV2ViQmFzZU5ldHNjYXBlUGx1Z2luU3RyZWFtLm1tCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdl YktpdC9QbHVnaW5zL1dlYkJhc2VOZXRzY2FwZVBsdWdpblN0cmVhbS5tbQkocmV2aXNpb24gMjUw MTMpCisrKyBXZWJLaXQvUGx1Z2lucy9XZWJCYXNlTmV0c2NhcGVQbHVnaW5TdHJlYW0ubW0JKHdv cmtpbmcgY29weSkKQEAgLTI5NSw2ICsyOTUsOCBAQCBzdGF0aWMgU3RyZWFtTWFwJiBzdHJlYW1z KCkKIC0gKHZvaWQpc3RhcnRTdHJlYW1XaXRoUmVzcG9uc2U6KE5TVVJMUmVzcG9uc2UgKilyCiB7 CiAgICAgTlNNdXRhYmxlRGF0YSAqdGhlSGVhZGVycyA9IG5pbDsKKyAgICBsb25nIGxvbmcgZXhw ZWN0ZWRDb250ZW50TGVuZ3RoID0gW3IgZXhwZWN0ZWRDb250ZW50TGVuZ3RoXTsKKwogICAgIGlm IChbciBpc0tpbmRPZkNsYXNzOltOU0hUVFBVUkxSZXNwb25zZSBjbGFzc11dKSB7CiAgICAgICAg IE5TSFRUUFVSTFJlc3BvbnNlICpodHRwUmVzcG9uc2UgPSAoTlNIVFRQVVJMUmVzcG9uc2UgKily OwogICAgICAgICB0aGVIZWFkZXJzID0gW05TTXV0YWJsZURhdGEgZGF0YVdpdGhDYXBhY2l0eTox MDI0XTsKQEAgLTMzMSwxMSArMzMzLDE4IEBAIHN0YXRpYyBTdHJlYW1NYXAmIHN0cmVhbXMoKQog ICAgICAgICAgICAgW3RoZUhlYWRlcnMgYXBwZW5kQnl0ZXM6IlxuIiBsZW5ndGg6MV07CiAgICAg ICAgIH0KIAorICAgICAgICAvLyBJZiB0aGUgY29udGVudCBpcyBlbmNvZGVkIChtb3N0IGxpa2Vs eSBjb21wcmVzc2VkKSwgdGhlbiBkb24ndCBzZW5kIGl0cyBsZW5ndGggdG8gdGhlIHBsdWdpbiwK KyAgICAgICAgLy8gd2hpY2ggaXMgb25seSBpbnRlcmVzdGVkIGluIHRoZSBkZWNvZGVkIGxlbmd0 aCwgbm90IHlldCBrbm93biBhdCB0aGUgbW9tZW50LgorICAgICAgICAvLyA8cmRhcjovL3Byb2Js ZW0vNDQ3MDU5OT4gdHJhY2tzIGEgcmVxdWVzdCBmb3IgLVtOU1VSTFJlc3BvbnNlIGV4cGVjdGVk Q29udGVudExlbmd0aF0gdG8gaW5jb3Jwb3JhdGUgdGhpcyBsb2dpYy4KKyAgICAgICAgTlNTdHJp bmcgKmNvbnRlbnRFbmNvZGluZyA9IChOU1N0cmluZyAqKVtbKE5TSFRUUFVSTFJlc3BvbnNlICop ciBhbGxIZWFkZXJGaWVsZHNdIG9iamVjdEZvcktleTpAIkNvbnRlbnQtRW5jb2RpbmciXTsKKyAg ICAgICAgaWYgKGNvbnRlbnRFbmNvZGluZyAmJiAhW2NvbnRlbnRFbmNvZGluZyBpc0VxdWFsVG9T dHJpbmc6QCJpZGVudGl0eSJdKQorICAgICAgICAgICAgZXhwZWN0ZWRDb250ZW50TGVuZ3RoID0g LTE7CisKICAgICAgICAgLy8gc3RhcnRTdHJlYW1SZXNwb25zZVVSTDouLi4gd2lsbCBudWxsLXRl cm1pbmF0ZS4KICAgICB9CiAKICAgICBbc2VsZiBzdGFydFN0cmVhbVJlc3BvbnNlVVJMOltyIFVS TF0KLSAgICAgICAgICAgZXhwZWN0ZWRDb250ZW50TGVuZ3RoOltyIGV4cGVjdGVkQ29udGVudExl bmd0aF0KKyAgICAgICAgICAgZXhwZWN0ZWRDb250ZW50TGVuZ3RoOmV4cGVjdGVkQ29udGVudExl bmd0aAogICAgICAgICAgICAgICAgIGxhc3RNb2RpZmllZERhdGU6V0tHZXROU1VSTFJlc3BvbnNl TGFzdE1vZGlmaWVkRGF0ZShyKQogICAgICAgICAgICAgICAgICAgICAgICAgTUlNRVR5cGU6W3Ig TUlNRVR5cGVdCiAgICAgICAgICAgICAgICAgICAgICAgICAgaGVhZGVyczp0aGVIZWFkZXJzXTsK