No subject

Web applications benefit from being built on top of a thin layer.

WebKit is using get() on header names found in HTTPHeaderNames.in.
To take that into account, we can optimize get() for some/all of those header names.

This can be achieved using dedicated member fields, or an additional hashmap<HTTPHeaderName, index> or even a vector given the number of common header names (< 100).
For those "indexed" header names, a header entry could also store the index to the next header with the same name.

<span class="quote">&gt; &gt; For instance, keeping-first-index mechanism might be triggered when header
&gt; &gt; set size is above a given threshold. 
&gt; This would make it hard to find bugs that only appear in large lists or near
&gt; the threshold.</span >

I agree in general. At the same time, it does not sound too difficult to add suffficient test coverage for it.

<span class="quote">&gt; &gt; Or it can be done lazily when a header is actually get.
&gt; This would make get slow.</span >

get would be slow the first time only, and only if number of headers N is very large.
If we look at a typical case when processing a message (request or response), there will be N append operations and M get operations. 
But M is much smaller than N when N becomes large.
Having a fast append is appealing, having an amortized fast get sounds reasonnable to me.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>
--1452508412.3F1c4.26083--