HTML and CSS Reference
In-Depth Information
HTTP Streaming
HTTP
streaming
is very similar to HTTP long-polling, except the connection isn't closed when new data is available or
at a given interval. Instead, new data is pushed over the existing connection which remains open.
The conversation between client and server now becomes the following:
CLIENT: Hi! Can I have some data? And please let me know whenever any new data comes along.
SERVER: Sure. Here you go!
[time passes]
SERVER: I have new data for you! Here you go!
[time passes]
SERVER: I have more new data for you! Here you go!
The benefit of this solution is that the connection between the client and server is persisted so the instant new
data is available it can be sent to the client, and any new data after that is also sent over the same connection. This
ensures that the server and client are kept in sync.
HTTP streaming does still suffer from an inability to offer bidirectional communication and therefore the
potential resource implications associated with the necessity to use a second connection for client-to-server
communication.
One big problem with the HTTP streaming approach is the inconsistencies of how it is achieved within different
web browsers. In Gecko-based browsers, it is possible to use multipart replace headers which indicate to the browser
to replace the older content that was last received with newer content. In other browsers this isn't possible, so the
response buffer keeps on growing until there is no other choice but to close and reopen the connection to the server.
Additional Problems with HTTP-based Solutions in Web Browsers
The requirement to use multiple connections for bidirectional communication and cross-browser implementation
differences isn't the only problem with HTTP-based solutions. Browsers also restricted the destination of HTTP
requests from a web page and the number of connections that could be established.
The capability for JavaScript running in a web page to make a request to the server has long been restricted
to only allowing a request to the same domain.
7
For example, if the web page is
www.example.com/index.html
,
JavaScript could only make a request to a resource on
www.example.com
or by manipulating the value of
document.domain
in JavaScript, it is possible to make a request to any
example.com
subdomain such as
sub.example
.
com
. This restriction was put in place by browser vendors for security reasons but, as with a number of security
restrictions, it blocked the legitimate use cases for making a request to other domains. The need to make these
requests has now been addressed with cross-origin resource sharing (CORS).
8
CORS has good browser support,
9
but there are obvious older browser considerations.
The restriction on the number of connections that could be made was enforced per-domain e.g. requests to
www.example.com
.
In earlier browsers, this meant as few as two connections could only be made to the same domain.
For HTTP-based solutions, this meant that you could only have one page of a web app or site open which was using
HTTP long-polling or streaming. If you tried to open a second page the connections would fail. The workaround for
this was to have lots of subdomains that mapped back to the same server. Connection restrictions are still enforced in
modern browsers, but the number of connections allowed is now much more reasonable.
10
7
9
Search WWH ::
Custom Search