Re: Holding connections open: an immodest proposal

Rick Troth (
Wed, 14 Sep 1994 09:48:51 -0500

On Sep 14, 11:57am, HALLAM-BAKER Phillip wrote:

> It is important to distinguish two cases :-
> 1) Loading all data segments associated with an object (eg html + inline images)
> 2) Contiuous mode connection for realtime response.
> 1 is solved best through use of MIME multipart type. The browser does a request
> and gets back the complete object as a single document, inline images and all.
> This is currently being added to the library but slowly :-(

You may have solved it (below), but if not then there remains
the problem of non-graphical clients getting a big multipart object
with GIFs it can't use.

> There are two ways of doing this :
> 1) The server sends back everything as a unit
> 2) The client requests the inline images separately.
> The Server is actually in the best position to know whether an image
> is specific to one html or shared by many. ...

Eeeshh... but that could mean a lot of work.

Remember, some (many?) servers are quite ignorant of HTML.

> The second method requires a slight chnge to the specs. Where we have at the
> moment
> GET /path/fred.html http/1.0
> I want to have
> GET /path/ http/1.0
> Relative-URI: fred.html
> Relative-URL: jim.html

This could, I think, handle the problem above. A text-only
client (or a GUI with "load images" switched off for speed) here has
the option to not list the relative URLs.

> 3) Multipart MIME, the content length is not required for the outermost body
> but must be there for all the innermost objects.

No it doesn't. This is how multipart might provide the needed
EOF indicator (which I will mention in another note). Look for the boundary.
Boundary lines must be guaranteed to be unique, or must be out-of-band w/r/t
the data they delimit. But it works.

> 4) Need transaction methods:-
> START (Implicit at begin of transaction)

It's worth mentioning that these apply to POSTing (or GETting
with arguments) but not to R/O transactions. (I could be wrong; if so
it would help us all if someone pointed out how and why)

> It is important to distinguish the original point of HTTPs single shot nature
> from the need for continous connections to provide functionality. FTP and
> SMTP do not need to keep the connection. The fact that they do slows down
> the process significantly. In the same way SMTP should be single shot.

I don't see how SMTP's connection keeping is harmful.
I can see it in FTP, especially for the single-shot retrievals we're
doing now with multiprotocol WWW browsers, but how is SMTP slow because
it waits for that final QUIT?

> One point:

Maybe. Just maybe.

> --
> Phillip M. Hallam-Baker
> Not Speaking for anyone else.