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

On Wed, 26 Mar 1997, 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.
> 

Ben may have been brusque, but he is basically correct.  

> 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...

HTTP/1.1 provides for pipelining requests.  When pipelining is used
there is no functional difference between <img src="foo.png"> and the 
<img src=deferred id=ID> you suggest.  Gettys and Freier are
discussing something else, for example, letting the client know about
a server's policy concerning maximum allowed idle time or maximum
number of pipelined GETs permitted..

> 
> 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.
> 

I think that Ben Laurie was pointing out that the server can't really
know "when all the inlined entities have been sent" since some may be
in the browser's cache, but the client surely knows when they have
been received so it is not clear why it would need a close-connection 
hint.

> 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.  

As mentioned above this functionality currently exists with HTTP/1.1
and pipelining.

> 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...

This functionality does not exist, but that is a problem with HTML not
HTTP..  One of the major failings of HTML is its inability to do 
"client side includes" i.e. the equivalent of <img src="foo.png">
for text rather than images.

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Wednesday, 26 March 1997 11:51:59 UTC