[MIGRATED] Make deprecation warnings on XHR's setRequestHeader more accurate

This CL is migrated to https://codereview.chromium.org/1378543002/ due to repository merge.

Make deprecation warnings on XHR's setRequestHeader more accurate

The deprecation warnings were shown for the following three kinds of header values:
1. Header values with control octets,
2. Header values with leading/trailing whitespaces,
   but normalization doesn't have effect (because other parts of Chromium
   strip such whitespaces before sent to network), and
3. Header values with leading/trailing whitespaces
   and normalization does have effect. For example, in the case of calling
   setRequestHeader('test', 'a ') and setRequestHeader('test', ' b'),
   the whitespaces remains in the middle of the header value ('test: a ,  b')
   and will be removed by normalization.

This CL
- Suppresses deprecation warnings for 2.
- Creates a separate deprecation counter for 3.
- Mentions in the warning message that we are experimenting.
- Adds tests.

BUG=455099

[hiroshige, 2015-09-15 08:01:05]

The CQ bit was checked by hiroshige@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-09-15 08:01:13]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1342443004/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1342443004/1

[commit-bot: I haz the power, 2015-09-15 08:10:21]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-15 08:10:22]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[hiroshige, 2015-09-15 08:26:12]

The CQ bit was checked by hiroshige@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-09-15 08:26:16]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1342443004/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1342443004/20001

[hiroshige, 2015-09-15 09:00:20]

hiroshige@chromium.org changed reviewers:
+ shiva.jm@samsung.com, tyoshino@chromium.org

[hiroshige, 2015-09-15 09:00:20]

shiva.jm@ and tyoshino@ (core/xmlhttprequest OWNER), could you take a look?

[commit-bot: I haz the power, 2015-09-15 10:21:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-15 10:21:41]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[hiroshige, 2015-09-15 10:46:31]

The CQ bit was checked by hiroshige@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-09-15 10:46:36]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1342443004/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1342443004/40001

[commit-bot: I haz the power, 2015-09-15 13:45:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-15 13:45:33]

Dry run: This issue passed the CQ dry run.

[shiva.jm, 2015-09-16 08:29:05]

On 2015/09/15 09:00:20, hiroshige wrote:
> shiva.jm@ and tyoshino@ (core/xmlhttprequest OWNER), could you take a look?

changes looks fine.

[tyoshino (SeeGerritForStatus), 2015-09-25 13:01:35]

Sorry for delay

https://codereview.chromium.org/1342443004/diff/40001/Source/core/frame/UseCo...
File Source/core/frame/UseCounter.cpp (right):

https://codereview.chromium.org/1342443004/diff/40001/Source/core/frame/UseCo...
Source/core/frame/UseCounter.cpp:958: return "Header values not matching to RFC
7230 (containing invalid octets). We are experimenting whether such header
values can be deprecated (see:
https://www.chromestatus.com/feature/6457425448140800).";
"Found a header value that doesn't match the field-content token production
(containing invalid octets. see RFC 7230)."

and, how about explaining what's actually planned instead of "deprecate"? E.g.

'... we can throw for such header values"

https://codereview.chromium.org/1342443004/diff/40001/Source/core/frame/UseCo...
Source/core/frame/UseCounter.cpp:961: return "setRequestHeader() affected by
header value normalization (header values with leading/trailing whitespaces). We
are experimenting whether such whitespaces can be stripped according to the
latest spec (see: https://www.chromestatus.com/feature/6457425448140800).";
According to the Fetch Standard, setRequestHeader() must strip leading/trailing
whitespaces, but it doesn't currently. We are experimenting whether we can make
it conform to the spec (see ...). This script will be affected by the change.

https://codereview.chromium.org/1342443004/diff/40001/Source/core/frame/UseCo...
File Source/core/frame/UseCounter.h (right):

https://codereview.chromium.org/1342443004/diff/40001/Source/core/frame/UseCo...
Source/core/frame/UseCounter.h:844: XHRSetRequestHeaderAffectedByNormalize =
954,
Normalization

https://codereview.chromium.org/1342443004/diff/40001/Source/core/xmlhttprequ...
File Source/core/xmlhttprequest/XMLHttpRequest.cpp (right):

https://codereview.chromium.org/1342443004/diff/40001/Source/core/xmlhttprequ...
Source/core/xmlhttprequest/XMLHttpRequest.cpp:1187: if
(FetchUtils::isForbiddenHeaderName(name)) {
Let's move this to the right place so that we won't forget to apply this check
on the result of normalization when we do the deprecation.

https://codereview.chromium.org/1342443004/diff/40001/Source/core/xmlhttprequ...
Source/core/xmlhttprequest/XMLHttpRequest.cpp:1204: if (!result.isNewEntry) {
if (result.isNewEntry)
    return;

....

https://codereview.chromium.org/1342443004/diff/40001/Source/core/xmlhttprequ...
Source/core/xmlhttprequest/XMLHttpRequest.cpp:1217: if
(FetchUtils::normalizeHeaderValue(newValue) != normalizedNewValue) {
omit {}

[shiva.jm, 2015-09-28 11:07:37]

dependent CL: https://codereview.chromium.org/1364993003/,
is commited now.

[hiroshige, 2015-09-29 05:19:09]

I'll also migrate this CL due to repository merge.

https://codereview.chromium.org/1342443004/diff/40001/Source/core/frame/UseCo...
File Source/core/frame/UseCounter.cpp (right):

https://codereview.chromium.org/1342443004/diff/40001/Source/core/frame/UseCo...
Source/core/frame/UseCounter.cpp:958: return "Header values not matching to RFC
7230 (containing invalid octets). We are experimenting whether such header
values can be deprecated (see:
https://www.chromestatus.com/feature/6457425448140800).";
On 2015/09/25 13:01:35, tyoshino wrote:
> "Found a header value that doesn't match the field-content token production
> (containing invalid octets. see RFC 7230)."
> 
> and, how about explaining what's actually planned instead of "deprecate"? E.g.
> 
> '... we can throw for such header values"

Done.

https://codereview.chromium.org/1342443004/diff/40001/Source/core/frame/UseCo...
Source/core/frame/UseCounter.cpp:961: return "setRequestHeader() affected by
header value normalization (header values with leading/trailing whitespaces). We
are experimenting whether such whitespaces can be stripped according to the
latest spec (see: https://www.chromestatus.com/feature/6457425448140800).";
On 2015/09/25 13:01:35, tyoshino wrote:
> According to the Fetch Standard, setRequestHeader() must strip
leading/trailing
> whitespaces, but it doesn't currently. We are experimenting whether we can
make
> it conform to the spec (see ...). This script will be affected by the change.

Done.

https://codereview.chromium.org/1342443004/diff/40001/Source/core/frame/UseCo...
File Source/core/frame/UseCounter.h (right):

https://codereview.chromium.org/1342443004/diff/40001/Source/core/frame/UseCo...
Source/core/frame/UseCounter.h:844: XHRSetRequestHeaderAffectedByNormalize =
954,
On 2015/09/25 13:01:35, tyoshino wrote:
> Normalization

Done.

https://codereview.chromium.org/1342443004/diff/40001/Source/core/xmlhttprequ...
File Source/core/xmlhttprequest/XMLHttpRequest.cpp (right):

https://codereview.chromium.org/1342443004/diff/40001/Source/core/xmlhttprequ...
Source/core/xmlhttprequest/XMLHttpRequest.cpp:1187: if
(FetchUtils::isForbiddenHeaderName(name)) {
On 2015/09/25 13:01:35, tyoshino wrote:
> Let's move this to the right place so that we won't forget to apply this check
> on the result of normalization when we do the deprecation.

This check is on the header name, not the header value, so thus is not related
to header value update issues.

https://codereview.chromium.org/1342443004/diff/40001/Source/core/xmlhttprequ...
Source/core/xmlhttprequest/XMLHttpRequest.cpp:1204: if (!result.isNewEntry) {
On 2015/09/25 13:01:35, tyoshino wrote:
> if (result.isNewEntry)
>     return;
> 
> ....

Done.

https://codereview.chromium.org/1342443004/diff/40001/Source/core/xmlhttprequ...
Source/core/xmlhttprequest/XMLHttpRequest.cpp:1217: if
(FetchUtils::normalizeHeaderValue(newValue) != normalizedNewValue) {
On 2015/09/25 13:01:35, tyoshino wrote:
> omit {}

Done.

[hiroshige, 2015-09-29 05:37:35]

This CL is migrated to:
https://codereview.chromium.org/1378543002/

[tyoshino (SeeGerritForStatus), 2015-09-29 08:43:28]

https://codereview.chromium.org/1342443004/diff/40001/Source/core/xmlhttprequ...
File Source/core/xmlhttprequest/XMLHttpRequest.cpp (right):

https://codereview.chromium.org/1342443004/diff/40001/Source/core/xmlhttprequ...
Source/core/xmlhttprequest/XMLHttpRequest.cpp:1187: if
(FetchUtils::isForbiddenHeaderName(name)) {
On 2015/09/29 05:19:09, hiroshige wrote:
> On 2015/09/25 13:01:35, tyoshino wrote:
> > Let's move this to the right place so that we won't forget to apply this
check
> > on the result of normalization when we do the deprecation.
> 
> This check is on the header name, not the header value, so thus is not related
> to header value update issues.

Ouch. Never mind.