Jon> This is quite true IMHO. It begs the question why are people
Jon> so intent on using a stateless protocol for doing inherently
Jon> non-stateless operations? HTTP isn't as far as I'm aware
Jon> intended to become the One True Protocol(tm) such that nobody
Jon> will implement anything else. If you need stateful
Jon> transactions, why not come up with a separate stateful
Jon> protocol rather than breaking the clean statelessness of HTTP
Jon> which has been so useful to date?
Although the proposed hacks to TCP for transaction processing will make
this better, it does seem to me that adding support for multiple
transactions over the same connection would be a big win. Using MIME is
not a very good solution in this case, as the vast bulk of all secondary
transactions are binary files, and having to scan through byte by byte
for the end marker is a major lose.
What we have here is a textbook case of where a session protocol is
actually useful; fortunately we have a good example to look at when
designing a session protocol. All we have to do is look at the OSI session,
and then make sure to do exactly the opposite. Since OSI session has every
possible design flaw in there somewhere, all that's left is perfection :)
As a first cut, how about something like the following (this is vaguely
similar to IMAP in the way that each transaction has an ID associated with
it, to allow requests and responses to be streamed.
> HOLD / HTTP/1.1
> [various accept lines, followed by blank line]
< HTTP/1.1 200 OK
> START-SESSION 1
< HTTP/1.1 xxx 1 started
> 1 GET /
< HTTP/1.1 200 1 OK
< DATA 1 8192
< [8192 bytes]
< DATA 1 200
< [200 bytes]
< END 1
> START-SESSION 2
< HTTP/1.1 xxx 2 started
> 2 GET foo.gif
< HTTP/1.1 200 2 OK
[etc]
Simon