W3C home > Mailing lists > Public > www-talk@w3.org > May to June 2000

RE: persistent conncetion HOL blocking

From: Joris Dobbelsteen <j.p.tdobbelsteen@freeler.nl>
Date: Sat, 13 May 2000 20:53:59 +0200
To: "'young ka ming'" <kmyoung7@ie.cuhk.edu.hk>
Cc: "WWW WG \(E-mail\)" <www-talk@w3.org>
Message-ID: <000201bfbd0c$994bc480$0e0aa8c0@THUIS.LOCAL>
Most HTTP servers send the content-length header before the actual file is
transmitted. Connections that have no content-length header (and are not
(chunked) encoded) close the connection after the request has finished. So
here you cannot send a subsequent request.

The issue is with chunked transfers, because you don't know the size of the
file, however, files send with chunked transfer encoding are, i hope, small
files: This technique was designed to allow active (scripting, CGI, ASP,
e.d.) content to be transmitted, before the file length is known. Normally
these files are not to large, only a couple KBs.
Large files like MP3, ZIP, EXE, e.d. are static files, and the length is
known before the file is actually send. So HTTP clients should wait for the
first reponse (not data) to be received, before making a subsequent

Otherwise servers should close the connection (connection: close) before
sending a huge file (won't cause to much network overhead for really large


-----Original Message-----
From: young ka ming [mailto:kmyoung7@ie.cuhk.edu.hk]
Sent: vrijdag 12 mei 2000 9:10
To: Jeffrey Mogul
Cc: http-wg@cuckoo.hpl.hp.com
Subject: Re: persistent conncetion HOL blocking


Thank you so much for enlightening me.

How could a client know in advance that it will have got a hugh response
so that it opens another connection?
specification by file type?


On Thu, 11 May 2000, Jeffrey Mogul wrote:

> Kaming Young writes:
>     HOL blocking means Head Of Line blocking
>     What i mean is consider Alice send out a request for a large latest
>     hit MP3 file and then a request for a small text file which both
>     resides on the same server.  so the response for MP3 file will
>     block the second response and the response that follow in the
>     persistent connection case.
> The HTTP/1.1 Draft Standard (RFC2616) address the head-of-line
> blocking issue with respect to proxies, in section 8.1.4, where
> it says:
>    			A proxy SHOULD use up to 2*N connections to
>    another server or proxy, where N is the number of simultaneously
>    active users.
> I can't remember why we didn't say "to avoid head-of-line blocking"
> in this sentence, since this is precisely the reason for saying
> that proxies aren't expected to multiplex lots of clients on
> one connection.
> The same paragraph says:
>    A single-user client SHOULD NOT maintain more than 2 connections
>    with any server or proxy.
> The reasoning behind that requirement is related to a kind of
> head-of-line blocking.  Consider a client loading a long HTML
> page with lots of images.  The client should probably start
> the process of loading the images (on connection #2) while
> continuing to load the HTML (on connection #1); we don't want
> the images blocked until the entire HTML file is loaded.
> I'm not sure it makes sense for a single browser window to
> be simultaneously loading a text file and an MP3 file, but
> I guess it would make sense for a single user to be loading
> both in separate windows of a single browser application.
> Even so, the spec still allows these two simultaneous connections.
> Anyway, we never specifically defined "single-user", so I
> think a client implementor should use good judgement in
> deciding whether a browser with multiple active windows
> counts as one "user" or several.
> The point of these requirements was not to force people to
> suffer from head-of-line blocking.  It was to allow the
> implementation of clients and proxies that do not suffer
> from head-of-line blocking, while discouraging them from
> using more TCP connections than necessary.
> -Jeff
Received on Saturday, 13 May 2000 14:53:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:02 UTC