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!