The HTTP HOST header is a required component of HTTP/1.0. It tells the server the hostname the user is trying to access, and is required by the server when using name-based virtual hosts. The problem is that WebKit passes the HTTP HOST header as the last header in the request. This is sub-optimal for many reasons, not least of which is performance. TESTED ON: AppleWebKit/525.8+ But this has been the case for some time, including all shipping versions of Safari. I don't have the resource to test other platforms. EXAMPLE: Here's a request to http://www.webkit.org/ GET / HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_1; en-us) AppleWebKit/525.8+ (KHTML, like Gecko) Version/3.0.4 Safari/523.10.6 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us Accept-Encoding: gzip, deflate Cookie: __utmc=244758403 Connection: keep-alive Host: www.webkit.org IMPACT: Many large web hosts use name-based virtual hosts behind load balancers. In order for the load balancer to correctly route the request it may have to see the HOST header. Since this HOST header is last the load balancing algorithm cannot start to process the request until the entire request is received. For simple requests, like the above, the entire request may fit in a single IP packet, so the overhead may not be great, but if the site has many cookies the host header may not appear until the second, third, or even later packet. This adds a delay before the load balancer and/or server can start to process the request. Depending on network conditions this could be several hundred milliseconds and can lead to a perception of lower performance. By promoting the HOST header so that it appears earlier in the request, the load balancer/server can start to process the request sooner. Of course, the web server won't be able to process the page any faster if it depends on later request content such as cookies, but at least it's routed to the right server as quickly as possible, and milliseconds count. It is hard to prioritize which headers should have precedence but the URI and HOST are the two commonest methods used for load balancing, so it makes sense to position these as early in the request as possible.
I suspect that this happens at a layer below WebKit. If that is the case, this bug will need to be migrated to Radar.
<rdar://problem/5733608>
I also think that this is an issue below WebKit. Closing as INVALID per our process; this will continue to be tracked by Apple internally. Thank you for reporting this!