- From: Jeff de la Beaujardiere <delabeau@iniki.gsfc.nasa.gov>
- Date: Wed, 26 Mar 1997 13:54:27 -0500
- 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 UTC