HTTP a stateless protocol??

HTTP a stateless protocol??

Post by Arnold Hendrik » Tue, 23 May 2000 04:00:00




>> You are considering the implementation of the transport layer, of which
>> the Hypertext Transfer Protocol has no knowledge. TCP is not required.
> Ron, what do you mean TCP is not required? Not required for HTTP?
> How can this be so?

There's nothing stopping you from running HTTP over a unix pipe, for example.
All HTTP requires is a streaming connection. TCP is not part of the HTTP
specification and not part of its protocol.

--

B-Lex Information Technologies

PGPKey: 2048/75929DC1     92 F1 6D A4 86 5A AE 50  CF 78 01 5B 18 94 18 40

 
 
 

HTTP a stateless protocol??

Post by Robert Reimill » Tue, 23 May 2000 04:00:00



>There's nothing stopping you from running HTTP over a unix pipe, for example.
>All HTTP requires is a streaming connection. TCP is not part of the HTTP
>specification and not part of its protocol.

Right, from RFC2616 :
"HTTP only presumes a reliable transport; any protocol that provides
such guarantees can be used;...."

I guess if you could interface two cans and a string and make it
reliable you could use that :)

The return address is invalid. DO NOT email to this address.

 
 
 

HTTP a stateless protocol??

Post by Ronald Steedma » Tue, 23 May 2000 04:00:00



:>
:> You are considering the implementation of the transport layer, of which
:> the Hypertext Transfer Protocol has no knowledge. TCP is not required.

: Ron, what do you mean TCP is not required? Not required for HTTP?
: How can this be so?

 The specification of HTTP as written in the RFC that defines it states
 explicitely that HTTP is not restricted to TCP. My point is that HTTP
 is a distinct layer - to be treated on its own terms.

: I think calling an HTTP server stateless is pushing it too far.

 HTTP is referred to as stateless all the time, do a quick websearch for
 +stateless and +HTTP and you will find many references. An HTTP server
 is an entirely different question. If it has an ACTIVE/DISABLED toggle
 switch it is stateful, but that has nothing to do with the protocol

: There are two levels of state information here. At the application
: level, and then at the network level.

 Exactly. At the IP network layer it is stateless, and at the HTTP
 application layer it is stateless. The TCP layer in probably stateful.

: At the network level, it is certainly is a state-full session (it is
: TCP/IP after all), and as was mentioned, TCP must remember state
: information about the session.

: At the application level, one can argue that HTTP server is less
: state-full since it remembers or stores in it very little state about the
: client application. But one can also mention cookies and keep-alive
: attributes, which leads back to making HTTP server somewhat state-full
: during the life of the particular session with the particular client.

: Maybe we need a precise definition of what is a 'stateless' server (or
: program), (or by implication, a state-full server), and then we apply
: this definition on HTTP server to find out.

: Nasser

 Sure. Check http://www.whatis.com/stateful.htm.

 I think this, and the separate layers are the problems. I am talking
 about HTTP - not servers, TCP, IP, etc.

 Do a quick websearch on +HTTP +stateless and you should find a wealth
 of websites describing why the protocol is considered stateless.

 Cookies are session management devices are usually looked at as being
 at a higher layer of the protocol. For example, the RFCs say that they
 "place HTTP requests and responses within a larger context, which we
 term a 'session'".

 HTTP specifies a language to use to talk between clients and servers.
 Why should it be restricted to TCP? Any reliable transport mechanism
 that sends these messages should work. The defining RFC says so.

  -- Ron Steedman