tools/metrics/histograms/histograms.xml

Index: tools/metrics/histograms/histograms.xml
diff --git a/tools/metrics/histograms/histograms.xml b/tools/metrics/histograms/histograms.xml
index 1593ac61faa52e966e6e23b3d7808b92026939b9..7c9cbd3309ebd28ca5d199e19f7175d9a89fa062 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -22736,6 +22736,15 @@ http://cs/file:chrome/histograms.xml - but prefer this file for new entries.
   </summary>
 </histogram>
 
+<histogram name="Net.HttpRequestHeaderValueValidInRFC7230" enum="BooleanValid">
+  <owner>hiroshige@chromium.org</owner>
+  <summary>
+    The count of request header values valid/invalid in RFC 7230 (somehow

[davidben, 2015/09/30 16:38:18]

For each request header sent out, whether it is valid per RFC 7230.

+    inaccurate because a header value can be counted multiple times).
+    https://crbug.com/455099.

[davidben, 2015/09/30 16:38:18]

This description is very confusing. What do you mean by "somehow inaccurate
because a header value can be counted multiple times"? Are you saying this
because we might set a header repeatedly? If so, we should fix that. (Indeed
HttpRequestHeaders::SetHeader is a somewhat odd place to measure.)

[hiroshige, 2015/10/29 12:49:20]

Yes, a header value is counted multiple times while headers are passed across
layers.

An alternative is to check values in URLRequest, as you suggested, which will
remove the duplicated counts.
(Perhaps in StartJob() and OnHeadersComplete()?)

However, checks in URLRequest will miss headers set in layers under URLRequest
(e.g. HttpNetworkTransaction).
Is this OK?
(I think basically OK but I was not 100% sure, so I'd like to confirm)

[davidben, 2015/10/29 21:04:56]

I think that's fine. Headers set internally within //net should only be fixed
headers that are part of the HTTP protocol. One would hope all of those are
valid per RFC 7230! :-D

The one thing to think about is extensions and the NetworkDelegate. Probably you
want to sample in URLRequestHTTPJob (there's one per redirect leg that goes
through http/https), sometime after NotifyBeforeSendHeaders is resolved.

https://code.google.com/p/chromium/codesearch#chromium/src/net/url_request/ur...

(Or, if you want, sampling both before and after would tell us if it's
extensions or the URLRequest consumer, likely web content, that's doing it.)

[hiroshige, 2015/12/15 12:00:26]

Done.

+  </summary>
+</histogram>
+
 <histogram name="Net.HttpResponseCode">
   <owner>mmenke@chromium.org</owner>
   <summary>The count of HTTP Response codes encountered.</summary>
@@ -22749,6 +22758,15 @@ http://cs/file:chrome/histograms.xml - but prefer this file for new entries.
   </summary>
 </histogram>
 
+<histogram name="Net.HttpResponseHeaderValueValidInRFC7230" enum="BooleanValid">
+  <owner>hiroshige@chromium.org</owner>
+  <summary>
+    The count of response header values valid/invalid in RFC 7230 (somehow
+    inaccurate because a header value can be counted multiple times).
+    https://crbug.com/455099.

[davidben, 2015/09/30 16:38:18]

Ditto.

+  </summary>
+</histogram>
+
 <histogram name="Net.HttpServerProperties.UpdatePrefs"
     enum="HttpServerPropertiesUpdatePrefsLocation">
   <owner>rtenneti@chromium.org</owner>