PART II
Chapter 6: Networking Considerations 243
quite explainable if you look at the HTTP specification. According to the HTTP 1.1 spec
(www.w3.org/Protocols/rfc2616/rfc2616-sec8.html):Clients that use persistent connections SHOULD limit the number of simultaneous connections
that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2
connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another
server or proxy, where N is the number of simultaneously active users. These guidelines are
intended to improve HTTP response times and avoid congestion.If browsers implement this idea without modifications, they will be throttled to make at
most two connections to any single fully qualified domains. In the test case, all the connections
are spawned quickly per JavaScript, but they are not actually issued until there is an opening to
do so. Because the first two requests timeout, the other connections never get a chance to go
and thus timeout as well.NNOT EOTE Conventional wisdom online seems to suggest that Internet Explorer has the two-connection
limit and other browsers do not. This is simply not true. All HTTP-conforming browsers will
have this limitation.Beyond the Two-Connection Limit?
If you are constrained by the two-connection limit, there might appear to be a variety of
methods that could be employed. However, before you get your hopes up, we must point
out that none of them are optimal and all beg the question of whether this should be done.
Remember, you are breaking the HTTP specification by doing so.The False Promise of document.domain
The first approach we explore is one taken in traditional Web applications to speed up
image downloads. Here the two-connection limitation is skirted by noting the emphasis on
the fully qualified domain. You might decide to add multiple names to your server so it is
known as http://www.ajaxref.com, www1.ajaxref.com, www2.ajaxref.com, and so on. From the
browser’s point of view you could make two requests to each. This technique is often used
in Web page optimization for paralleling image requests (which explains why you might
see sites serving their images from images.ajaxref.com instead of the main site), but it is not
immediately appropriate with Ajax because of the same-origin security policy employed by
JavaScript. This policy, simply stated, indicates a script can only talk to a URL from the
domain from which it was issued. The domain is restrictive in the sense that http://www.bozo.com
will be different than bozo.com unless you loosen the restriction.
In JavaScript, it is possible to modify the strict same origin limitation by setting the
document.domain property. For example, to allow connections to any arbitrary domain
within ajaxref.com set:document.domain = "ajaxref.com";in the script and then it would seem that you’re free to make connections to any subdomain
you please within ajaxref.com. So, if you had a wildcard DNS entry, you could probably just
make up a machine name and spawn whatever number of connections you wanted.