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: Jeff de la Beaujardiere <delabeau@iniki.gsfc.nasa.gov>
Date: Wed, 26 Mar 1997 13:54:27 -0500
Message-Id: <199703261854.NAA27347@iniki.gsfc.nasa.gov>
To: http-wg@cuckoo.hpl.hp.com
Cc: ben@algroup.co.uk, jg@zorch.w3.org

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.

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.

--Jeff dLB


  = J-F Pitot de La Beaujardiere
  = delabeau@iniki.gsfc.nasa.gov
  = http://globe2.gsfc.nasa.gov/
Received on Wednesday, 26 March 1997 10:58:56 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:33 EDT