[Webkit-unassigned] [Bug 17216] New: Sub-optimal HTTP HOST header ordering

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Feb 8 11:27:06 PST 2008


           Summary: Sub-optimal HTTP HOST header ordering
           Product: WebKit
           Version: 525+ (Nightly build)
          Platform: Macintosh
               URL: http://www.apple.com/
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Page Loading
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: andrewo at liveworld.com

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

TESTED ON: AppleWebKit/525.8+
But this has been the case for some time, including all shipping versions of
I don't have the resource to test other platforms.


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-Language: en-us
Accept-Encoding: gzip, deflate
Cookie: __utmc=244758403
Connection: keep-alive
Host: www.webkit.org


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.

Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the webkit-unassigned mailing list