Multipart Messages in HTTP
Markus Stumpf <stumpf@informatik.tu-muenchen.de>
Errors-To: listmaster@www0.cern.ch
Date: Fri, 11 Mar 1994 01:44:35 --100
Message-id: <94Mar11.013926mesz.311468@hprbg5.informatik.tu-muenchen.de>
Errors-To: listmaster@www0.cern.ch
Reply-To: stumpf@informatik.tu-muenchen.de
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Markus Stumpf <stumpf@informatik.tu-muenchen.de>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Multipart Messages in HTTP
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1332
I have just read in
http://info.cern.ch/hypertext/WWW/Protocols/HTTP/Body.html
about the possibility for servers.
If I understand it right, the server does not need to close the connection
after the document is delivered, if it is possible to "detect the end
of the document" by the presence of a Content-Length: field.
Are there any possibilities for clients to send multipart-requests to
the server?
As with all the icons and little images the expensive part in fetching
a document is the connection setup.
If a client and a server "could hold the line" until either
1) the server must close the connection, as he can't predict the
length of the document (some data generating script or the like)
2) the client has all it want's to get for now (e.g. all the inlined
images to the document).
3) timout or failure occurs.
I checked, but I didn't find anything and as it looks the current
practice of the servers is to close the connection anyway.
Would it be a protocol viloation if the client would send another
e.g. GET after all the data of the former GET was read?
\Maex
--
______________________________________________________________________________
Markus Stumpf Markus.Stumpf@Informatik.TU-Muenchen.DE
http://www.informatik.tu-muenchen.de/~stumpf/