Add histograms for a number of hacks in the HTTP header parsing logic.

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 244c41c92f71bc787d1bf97d0282fc80d3ce61c4..9f605933e2c65b3a280075689c13ebeb0e108ca9 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -18627,6 +18627,15 @@ Therefore, the affected-histogram name has to have at least one dot in it.
   </summary>
 </histogram>
 
+<histogram name="Net.HttpHeaderParserEvent" enum="HttpHeaderParserEvent">
+  <owner>mmenke@chromium.org</owner>
+  <summary>
+    Records the frequency of a number of hacky HTTP header parsing rules are

[davidben, 2015/04/13 19:55:14]

Do we care more about frequency or proportion of responses being of this or that
type. I've always been kinda dubious of these "event" histograms from the
prerender side since their denominators are weird. They're hard to read.

[mmenke, 2015/04/13 21:12:21]

I agree with your dislike of event-based histograms.  Unfortunately, we need
some baseline other than the frequency with which other hacks are executed.  We
could record one separate histogram per hack, with used vs not-used, but these
will be are very high use histograms, even if they only have two buckets, and I
think the way they're stored, server side, means that results in a lot of
overhead.

Also, I expect we'll see much less than 1% of responses trigger any of these
hacks, so I'm hoping that we'll basically get percentage use (As hack frequency
drops to 0, <use of a particular hack> / (<requests> + <use count of all hacks>)
approaches the percentage of requests that use that particular hack.

[davidben, 2015/04/14 23:41:40]

I suppose UseCounter is the same deal. Are separate histograms that expensive
that 1 vs 3 high-use histograms makes a big difference? I would think that
they'd be a drop in the bucket. *shrug* Whatever.

(3 because SKIPPED_WS_PREFIX and SKIPPED_NON_WS_PREFIX can be part of the same
histogram.)

[mmenke, 2015/04/14 23:51:33]

I think that each increment of 1 results in another entry in a table, which is
what makes them expensive.

+    invoked.  Histogram should be removed after we have enough data to know if
+    we can remove the hacks.
+  </summary>
+</histogram>
+
 <histogram name="net.HttpIdentSrcURL" units="requests">
   <owner>tsepez@chromium.org</owner>
   <summary>
@@ -52496,6 +52505,14 @@ Therefore, the affected-histogram name has to have at least one dot in it.
   <int value="15" label="Negotiate Secure Server"/>
 </enum>
 
+<enum name="HttpHeaderParserEvent" type="int">
+  <int value="0" label="PARSER_INVOKED"/>
+  <int value="1" label="HTTP_09_RESPONSE"/>
+  <int value="2" label="ALLOWED_TRUNCATED_HEADERS"/>
+  <int value="3" label="SKIPPED_WS_PREFIX"/>
+  <int value="4" label="SKIPPED_NON_WS_PREFIX"/>
+</enum>
+
 <enum name="HttpPipelineStatus" type="int">
   <int value="0" label="Success"/>
   <int value="1" label="Redirected"/>