Add UMA for header values in XHR's setRequestHeader() checked against RFC 7230

third_party/WebKit/Source/core/frame/UseCounter.cpp

 /*
  * Copyright (C) 2012 Google, Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in the
@@ skipping 912 matching lines @@
     case PrefixedPerformanceSetResourceTimingBufferSize:
         return replacedBy("Performance.webkitSetResourceTimingBufferSize", "Performance.setResourceTimingBufferSize");
 
     case PrefixedPerformanceResourceTimingBufferFull:
         return replacedBy("Performance.onwebkitresourcetimingbufferfull", "Performance.onresourcetimingbufferfull");
 
     case FetchAPIRequestContext:
         return "Request.context is deprecated and will be removed in M46 (see: https://www.chromestatus.com/feature/5534702526005248).";
 
     case HeaderValueNotMatchingRFC7230:
-        return "Header values not matching to RFC 7230, will be deprecated (see: https://www.chromestatus.com/feature/6457425448140800).";
+        return "Found a header value that doesn't match the field-content token production (containing invalid octets. see RFC 7230). We are experimenting whether we can throw for such header values (see: https://www.chromestatus.com/feature/6457425448140800).";
+
+    case XHRSetRequestHeaderAffectedByNormalization:
+        return "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: https://www.chromestatus.com/feature/6457425448140800). This script will be affected by the change.";

[kinuko, 2015/09/29 12:51:33]

"We are experimenting whether..." the intention of these sentences' are unclear,
do we expect developers to change the code so that it own't be affected by the
potential future change?  If so probably just writing it would be better.  
(E.g. "... doesn't currently.  The current behavior might be changed to conform
to the spec (see https://..../) and your code will be affected by the change.")

[hiroshige, 2015/09/29 13:21:38]

"Just experimenting" is somehow accurate: we want to collect stats, became not
sure whether we can actually do the change (due to expanding the scope to //net
as a result of discussions).

Should we turn this stats into UMAs (without warnings), if still exposing these
deprecation warnings to developers is confusing?

 
     // Features that aren't deprecated don't have a deprecation message.
     default:
         return String();
     }
 }
 
 void UseCounter::count(CSSParserContext context, CSSPropertyID feature)
 {
     ASSERT(feature >= firstCSSProperty);
@@ skipping 28 matching lines @@
 UseCounter* UseCounter::getFrom(const StyleSheetContents* sheetContents)
 {
     // FIXME: We may want to handle stylesheets that have multiple owners
     //        http://crbug.com/242125
     if (sheetContents && sheetContents->hasSingleOwnerNode())
         return getFrom(sheetContents->singleOwnerDocument());
     return 0;
 }
 
 } // namespace blink