hi folks, i read about session tracking that http is a stateless protocol that means when a web browser makes a request to the web server, the web server send the browser a response back, at which points the web server forgets everything about that browser. i am wondering if any one could give me a piece of exampel i.e., codes that proves this concept and clears my doubt "how does web server forgets interaction with a client just made?". thanks.
Hi Friend (translation of your name), You can try this yourself by creating a few html pages, host them on a server and then make requests to these. Each time you request a page the http server treats it as a new request and it has no knowledge of the previous request you sent. I am not sure what the confusion is on this. Furthermore, this is not a Servlets specific issue that you seem to have. Servlets will come in where they fill in the shortcoming of http protocol and allow tracting session with the HttpSession class. hth
The secret to creativity is knowing how to hide your sources.
HTTP is a connectionless / sessionless protocol, so when a request-response ends, there is no connection maintained. A minimal HTTP server would have no way to associate the next request with the prior request, so it cannot keep state. (I'm writing one of these right now, and it keeps zero state because I haven't taught it how to keep any yet.) But, most real HTTP servers provide ways for programs (servlets, CGI, ASP, PHP, etc) to maintain state. The simplest technique is for the server software to create a session object, store it someplace in memory or fast disk, match it up to the next request from the same IP address and make it available to programs running on the server. Your programs can stuff data into the session on one request and pull it back out on the next request. More complex techniques include EJB stateful session beans and so on. Any of these techniques make your server stateful. You have to keep in mind how much memory you are using, how fast or slow disk storage might be, whether you can handle load balanced servers (request 2 might not go to the same box as request 1). This whole topic is one of the first great hurdles (a.k.a. geek fun) to be solved in web apps. Hope that explanation helped!
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jan 29, 2003
BTW: One definition of a "connection" between a client and a server is that the server maintains some information about the client. So saying that a connectionless protocol is stateless is a bit redundant. But it's still worth saying just to keep in at the front of your mind. Off topic: I find it fascinating the HTTP is a connectionless protocol, running on TCP which is connection oriented, running on IP which is connectionless. Whew! The whole architecture of protocol stacks is extremely cool.
Joined: Oct 26, 2002
thanks guys. i appreciate your help in this matter. i was wondering if there is any example that would demonstrate that the web server does not maitain any states of a request made by a browser or it's client. I have another quetion though; the followings are the code snippet;
both works. What is the purpose of using encodeURL()? could you please clarify me? thanks.
Joined: Jun 29, 2003
As a test, switch off the cookies on your web browser and see what happens, then read the below... Basically, the normal session tracking mode uses the cookies to store your session id on the machine, thus it can recognise your future requests and marry them upto the previous requests. If your are using the normal mode if session tracking and a user has switched off their cookies, they will be able to establish a session on your application. In order to overcome this, one has to use the encodeURL method, which re-writes the url with the session id, if it needs to do so. That is if your cookies are on, it will use them, otherwise it will append the jsessionid at the end of your URL. hth