Treat headers and HTTP status text as Latin-1

Treat headers and HTTP status text as Latin-1

We currently decode them as UTF-8, but they should be interpreted as Latin-1.
(XHR specs the relevant parameters as WebIDL ByteString.) For response headers,
this matches Firefox, IE, Opera 12, and Safari.  For status text, this matches
Firefox nightly, IE, Opera 12, and Opera. For request headers, this matches
Firefox nightly, Opera 12, and Safari.

Preparatory Blink CL disabled a layout test:
  https://src.chromium.org/viewvc/blink?revision=157238&view=revision

This CL will be followed by a Blink CL to fix and re-enable the test, throw
exception on non-Latin-1 setRequestHeader argument, and add a new layout test
to verify this behavior.

BUG=276769
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=222127

[davidben, 2013-09-06 18:53:39]

darin: You were the last person to touch this (a long time ago), and I'm
addressing one of your TODOs, so I guess you're the right person to review this?

+abarth since you reviewed the preparatory Blink CL.

-----

Plan for coordinating repositories:

1. Land https://codereview.chromium.org/23456013/ (done)
2. When Blink roll happens (done), land this change
3. When that lands, land Blink change to fix and re-enable the test and add
layout tests to verify this is exposed correctly through XHR. Also modify
isValidHTTPHeaderValue to check containsOnlyLatin1 so we throw an exception
instead of silently converting non-Latin-1 characters to ?.

-----

Results of tests for other browser behavior:

- Chrome 30.0.1599.14 beta:
  - decodes response header value as UTF-8
  - decodes statusText as UTF-8
  - non-ASCII in request header name not allowed
  - encodes request header value as UTF-8
- Safari 6.0.5 (8536.30.1)
  - decodes response header value as Latin-1
  - decodes statusText as Latin-1
  - non-ASCII in request header name not allowed
  - encodes request header value as Latin-1
  - silently truncates request header value at first non-Latin-1
    char
- Firefox 23.0.1
  - decodes response header value as Latin-1
  - decodes statusText as UTF-8
  - non-ASCII in request header name not allowed
  - encodes request header value as UTF-8
- Firefox Nightly 26.0a1 (2013-08-30)
  - decodes response header value as Latin-1
  - decodes statusText as Latin-1
  - non-ASCII in request header name not allowed
  - encodes request header value as Latin-1
  - throws TypeError if request header value has non-Latin-1
    chars
- IE 10.0.9200.166660
  - decodes response header value as Latin-1
  - decodes statusText as Latin-1
  - non-ASCII in request header name ALLOWED
    - encoded as UTF-8 it seems
  - encodes request header value as UTF-8
- Opera 12.16
  - decodes response header value as Latin-1
  - decodes statusText as Latin-1
  - non-ASCII in request header name not allowed
  - encodes request header value as Latin-1
  - throws DOMException/SYNTAX_ERR if request header value has
    non-Latin-1 chars

I believe per-spec, firefox-nightly's behavior is most correct. We're the only
ones that try to decode response header values as UTF-8. We're not the only ones
to encode request header values as UTF-8, but Firefox is changing there, and not
being able to round-trip headers correctly seems pretty silly.

[darin (slow to review), 2013-09-06 19:07:41]

LGTM

[darin (slow to review), 2013-09-06 19:08:03]

+cc:jshin

[commit-bot: I haz the power, 2013-09-09 17:14:12]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/davidben@chromium.org/23553007/2001

[commit-bot: I haz the power, 2013-09-09 17:21:09]

Step "update" is always a major failure.
Look at the try server FAQ for more details.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_cl...

[commit-bot: I haz the power, 2013-09-09 18:20:51]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/davidben@chromium.org/23553007/2001

[commit-bot: I haz the power, 2013-09-09 23:27:59]

Change committed as 222127