In steps 3 and 4, how does the client know
where the end of the document is? This seems
like the primary obstacle to multi-transaction HTTP.
I can see a couple of options:
1) Use the Content-Length: header. This may
place an extra strain on servers, especially for
objects that are generated on the fly like CGI
script outputs.
2) Use an encoding with an explicit ending delimiter, say
message/rfc822 in base64. (OK, bad idea.)
3) Define a new content-transfer-encoding based on
tag-length-value packets; clients would examine the
tag field to determine which packet was the last
one in the transaction, and the server wouldn't need
to determine the total message length beforehand.
> 5. Client sends a request to get each IMG over the same
> connection
> 6. Server responds to each request as usual, except without
> closing the connection
> 7. Client closes the connection.
Servers should also be able to close the connection
asynchronously (in case of a timeout or other reasons.)
If multi-transaction HTTP does get implememnted, shouldn't
it have a different version number? HTTP/1.1 or HTTP/SESSION?
--Joe English