Though it would be hard to "see" in a protocol study. HTTP has a one
probably that I would enjoy seeing fixed in the near future (it is my
personal beef with HTTP).
HTTP 1.0 example negotiating session:
Connection opened:
GET /index.html HTTP/1.0
[ batch of "Accept" and other headers sent,
mosaic sends about 1K worth ]
File is sent
Connection closed:
Connection opened (to the same host):
GET /logo.gif HTTP/1.0
[ batch of "Accept" and other headers sent,
mosaic sends about 1K worth ]
File is sent
Connection closed:
This is awful, since not only is there connection creation/tear down
expenses, but also retrasmission of "client information" to the server.
Also, since (from the survey of my server) most of the HTML documents
are ~1K in size, it means that twice the information is being sent
than necessary... Not good for a slow link..
This hopefully could get changed (HTTP 1.1?) into a protocol that
doesn't close the connection after one file is trasmitted, but rather
leaves it open for a "short" while. Where it is closed either through
a client "QUIT" or a server timeout.
--koblas@netcom.com