[5576] in www-talk@info.cern.ch
Re: Holding connections open: an immodest proposal
daemon@ATHENA.MIT.EDU (Rick Troth)
Wed Sep 14 12:35:56 1994
Date: Wed, 14 Sep 1994 18:12:22 +0200
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: troth@is.rice.edu
From: troth@is.rice.edu (Rick Troth)
To: Multiple recipients of list <www-talk@www0.cern.ch>
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)
> COMMIT
> ROLLBACK
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:
> BURN PRAGMAS !
> PRAGMAS ? - JUST SAY NO.
Maybe. Just maybe.
> --
> Phillip M. Hallam-Baker
>
> Not Speaking for anyone else.
