[webkit-reviews] review denied: [Bug 4648] Shockwave unable to load GZip'd text resources when server sends Content-Length header : [Attachment 6922] proposed fix

[bugzilla-request-daemon at opendarwin.org]

Darin Adler <darin at apple.com> has denied Darin Adler <darin at apple.com>'s
request for review:
Bug 4648: Shockwave unable to load GZip'd text resources when server sends
Content-Length header
http://bugzilla.opendarwin.org/show_bug.cgi?id=4648

Attachment 6922: proposed fix
http://bugzilla.opendarwin.org/attachment.cgi?id=6922&action=edit

------- Additional Comments from Darin Adler <darin at apple.com>
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.