Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I know sessions are in PHP, ASP, ASP.NET and probably in many other languages. In most cases session solve a problem which the language itself fails to solve. I am wondering

  1. Who created sessions and when were they first introduced?
  2. Was it a feature of a particular language first?
  3. Is the use of sessions limited to web browsers only? Or are they used in desktop applications as well?
share|improve this question
6  
Sessions are a networking concept that was adapted by all popular web oriented languages, as a mechanism of maintaining state. They don't solve a problem the language fails to solve, as they are part of the language. –  Yannis Rizos Feb 7 '12 at 18:54
1  
Do you mean HTTP sessions? –  jcmeloni Feb 7 '12 at 18:55
    
PHP Sessions, ASP Sessions where variable are stored in a session and they can be accessed from a different page. But I want more insight, where they came from, where else are they used –  Noname Feb 7 '12 at 18:58
1  
@YannisRizos: They're actually a part of the language definition itself? –  FrustratedWithFormsDesigner Feb 7 '12 at 18:59
2  
Dave, sorry but I don't understand what the problem is. I've linked to an article that explains the concept and @jcmeloni linked to the RFC that defines the implementation of the concept for HTTP. There is no simpler explanation to what sessions are, or where they come from. –  Yannis Rizos Feb 7 '12 at 19:22
show 7 more comments

2 Answers

Sessions are an answer to HTTP being a terrible protocol for most internet traffic. Sessions are a means of maintaining state, which has to be managed this way because HTTP is a stateless protocol, unlike most other commonly used protocols. Its the result of a poor choice made a long time ago, that worked well for what the internet was at that time, but has since caused a lot more problems, but its too late to change.

share|improve this answer
1  
HTTP is a pretty decent protocol for its intended use (and believe it or not, most WWW traffic today still fits the original situation). Doing stateful things with it was never a design goal, and semi-stateful effects (such as caching and content expiration) have been part of the standard from early on. If anyone is to blame for a bad decision, it's the people who started bending HTTP into things it wasn't meant for. –  tdammers Feb 7 '12 at 20:10
    
Statefull HTTP. Wow. The OS should manage thousands of cookies and session parameters for HTTP and send it back and forth just to save some space on the server, keeping it all in client's memory and wasting bandwidth? Wow, you're insane. –  Slawek Feb 7 '12 at 20:30
    
@Slawek for anything that's more than a simple webpage state is already taking up resources, making HTTP a sateful protocol or having an alternative wouldn't matter for most web traffic. –  Ryathal Feb 7 '12 at 21:26
3  
HTTP is a good protocol, because it's stateless. Design a stateful protocol and you are neck deep in trouble. The reason is, that IP networking is "best effort" and your connection can fall apart any time. And you have absolutely no clue whether the client crashed, network link broken or just congestion caused too many packets to drop. So you have to be able to reconstruct the state on reconnect. It's much easier to just construct it with each request and not bother keeping it when you can't rely on it anyway. –  Jan Hudec Feb 8 '12 at 10:47
add comment

Web clients (browsers) communicate with web servers using a protocol called HTTP. HTTP was deliberately designed to be a stateless protocol., that is each request and response stands on its own, the server doesn't retain any record of completed responses, and doesn't link together the series of requests from a single user. Why was HTTP designed to be stateless? Primarily because it makes HTTP servers much easier to design and code, and makes them much less demanding of memory. HTTP was designed primarily as an information retreival system and there was almost no notion of using it as an application programming platform. Even today most HTTP traffic consists of simple requests and responses with no need for state.

Around 1992-93 folks started writing web applications (as opposed to simple web pages). They immediately ran into a need to store the state of the application over multiple pages. They began writing extensions to the web server that could store and manage state using cookies and url rewriting to associate HTTP requests with particular sessions. As awkward as this is, it has the virtue of flexibility. If folks designing HTTP had tried to specify a general purpose state mechanism, they probably would have gotten it wrong, and we'd be stuck with it as part of the standard. ASP, PHP, JSP, and the other server side scripting languages are the offspring of those old web server extensions.

Many other network applications use the notion of a session (SSH and SMTP for example), but the contents of the session are hardwired to the details of that application.

share|improve this answer
1  
The crucial extensions happened on the client: without client-side support for cookies, you won't get very far with your sessions. Servers tend to be relatively flexible, because you control them, but the client is where you have to take what you get. –  tdammers Feb 7 '12 at 20:06
2  
Actually cookies are not a pre-requisite for maintaining sessions, though they certainly make it easier. Anything you can do with cookies you can do with URL rewriting, making the session identifier a part of any URL passed back to the client. It's awful, but it can be (and was) done. –  Charles E. Grant Feb 7 '12 at 20:16
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.