W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: HTTP Connection Management (draft-ietf-http-connection-00.txt)

From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
Date: Thu, 27 Mar 1997 11:26:53 +0000 (GMT)
To: delabeau@iniki.gsfc.nasa.gov
Cc: http-wg@cuckoo.hpl.hp.com, ben@algroup.co.uk, jg@zorch.w3.org
Message-Id: <9703271126.aa29506@gonzo.ben.algroup.co.uk>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2925
Jeff de la Beaujardiere wrote:
> Ben Laurie writes:
> > Eh? The server doesn't know when the content is complete - but the client
> > does.  This suggestion would seem, therefore, to be both pointless and
> > impractical.
> Thanks for your polite, constructive criticism.  As a new contributor, I
> find it refreshing.

It was not my intention to be rude, just brief. Please accept my apologies.

> Consider the case of an application which generates content on request, say
> a geographic map encased in an HTML form providing a user interface to
> select a new map.  In the current scheme of things, the HTML goes out the
> door with tags like <img src="foo.png"> and <input type=image
> src="bar.gif">.  The client then issues a new GET for each embedded entity.
> A simple persistent connection scheme like Apache's keep-alive will help but
> does not address the issues discussed by Gettys and Freier
> [draft-ietf-http-connection-00.txt].
> In a more sophisticated implementation, a close-connection hint would be
> both useful and practical.  Padmanabhan and Mogul
> [http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLatency.html],
> for example, propose pipelining requests using GETALL or GETLIST methods.
> The server could easily append such a hint to the response.  That doesn't
> mean the client cannot also test for completeness and decide to close the
> connection; the request by Gettys was for comments on the server providing a
> hint, not an order, to this effect.
> Indeed, even without adding these new methods to HTTP a clever server could
> parse a static HTML document and intelligently manage the client's
> persistent connection to issue a close-connection hint when all the inlined
> entities have been sent.
> In the case of dynamic content like the example above, I envision HTTP and
> HTML enhancements that would permit responding to a single "GET mumble.cgi"
> request with a single stream of data punctuated by Content-type and
> Content-length headers (like the chunked encoding but containing multiple
> entities).  The enclosing HTML is sent first and contains tokens like <img
> src=deferred id=ID>; it is followed by ID-tagged blocks of data to populate
> the deferred inline items.  I would even like to defer some of the HTML
> using, say, <div src=deferred id=ID> so that I can respond to the request by
> sending the HTML immediately, inserting into the document the map requested
> when it is ready, and then inserting more HTML listing the data values
> reported by the stations shown on the map.  Adding a close-connection hint
> to such an application would be both feasible and desirable.

OK, so you're asking the server to parse all the content it serves. There are
several problems with this kind of approach:

1. Servers typically have a heavier load than clients, and therefore less
processing power available for parsing.

2. Clients have to parse the content anyway.

3. Servers do not necessarily understand the content (it may be a Java class
file, VRML or similar - which may have embedded references to further content,
but the server won't know that).

4. If a server is distributed across multiple processes, or worse, multiple
machines, it really can't tell what a client has seen and what it hasn't.

5. A server cannot know what is in a client's cache, so sending content
unsolicited is inefficient.

If this isn't very coherent, I blame my hangover, and I'll try again later ;-)



Ben Laurie                Phone: +44 (181) 994 6435  Email: ben@algroup.co.uk
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
London, England.          Apache-SSL author
Received on Thursday, 27 March 1997 03:31:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:19 UTC