Re: Statelessness

• Mail folder: WWW Talk Apr 94-present
• Next message: Garrett Arch Blythe: "Announce: Lynx 2-3 Release"
• Previous message: Simon E Spero: "Re: Performance analysis questions "
• Reply: Simon E Spero: "Re: statelessness "

Errors-To: listmaster@www0.cern.ch
Date: Wed, 18 May 1994 04:52:24 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9405180138.AA20717@tipper.oit.unc.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: ses@tipper.oit.unc.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Simon E Spero <ses@tipper.oit.unc.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Statelessness 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

>>>>> "Jon" == Jon P Knight <J.P.Knight@lut.ac.uk> writes:


    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