- From: David - Morris <dwm@shell.portal.com>
- Date: Thu, 15 Dec 1994 22:54:32 -0800 (PST)
- To: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
On Thu, 15 Dec 1994, Daniel W. Connolly wrote: > Ah... that reminds me: before we forget completely about HTTP/1.0, I > think the "Pragma: keep-connection" proposal (the idea; not > necessarily the syntax) is worth persuing in the short term. > > In other words: I agree that we should enhance clients and servers to > conduction multiple HTTP/1.0 transactions over the same connection. > > The Content-Type issues are a little sticky, but it's probably worth > persuing... It was pointed out at the IETF HTTP-ng BOF that the keep session open approach (whatever the syntax) applied to the client/proxy and proxy/server connections independently. As such the client/proxy could end up open a long time. (I would suspect a high performance proxy server could to virtual switching between client connections and idle server connections.) As I understood the discussion, multiple complete HTTP transactions would travel down the pipe so Content-Type issues should not vary from the current connection/transaction model. I think nothing I heard precludes a client from holding sessions open with multiple hosts or multiple sessions with one host. I for one find the human factors of the NETSCAPE approach much more satisfactory with early rendering of available information then sitting idle for long intervals waiting for a stupid company logo to be transfered or what ever. The SGML organization home page is particulariliy offensive as the first graphic fills the screen. Infering from observed behavior, I would speculate that the primary reason NETSCAPE opens multiple connections is to learn the shape of graphics to be included thereby making the rendering more useful. It might be nice in a future HTTP to consider restartable transactions such that a user interrupted transfer could be restarted at an intermediate point ... for that matter a long file transfer could restart. Dave
Received on Thursday, 15 December 1994 22:56:19 UTC