Tell me more ×
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.
up vote 3 down vote favorite

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

3 Answers

up vote 10 down vote

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
up vote -2 down vote

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
up vote -2 down vote

LOL, not sure why this wasn't mentioned sooner, but here is the Wiki all about computer(networking mostly) sessions. Generally sessions are now used in place of cookies, was they help deal with security issues and even allow for break through ways of using web software. For instance, you might have a sight that saves user data (with permission of course) such as computer they are on. Then based on their login from specific comps tied to their account you can maintain an active session (that acts like a cookie, except server side) across all their logins, thus allowing the user to be MUCH more flexible in use of your web-app. But that is really only 1 small and really poor example, fact is, anything you ever wanted to do with a cookie is pretty much replaced by use of sessions, as sessions are faster, more reliable, and as secure or insecure as you, the programmer, wants them to be.

Secondly, if you're looking to make better use of sessions through PHP then please allow me to recommend using CodeIgniter as it makes using sessions with good security an absolute breeze! Not to mention a very easy to use sight of documentation. Probably one of the best web-sight documentations of a library I've ever seen. It makes MSDN for .Net look like it was written by a 5th grader.

Of course, this is not all session types, I should probably mention, there are TelNet sessions, IP sessions, and more! Pretty much anything in networking has a session protocall, but it's most often seen in Web use now days as, and I mentioned before, it's the best new thing to hit web apps since sliced cookies!

It won't let me post more links but you can find a ton more info in the links I gave above and more CI's download at codeigniter.com

share|improve this answer
2  
The question is not about what is Sessions. The question is about the history of Session? Who started it, does it has an owner? Is this technology used in other non-web application as well? Ppl say there is a ton of information out there, ok but why not post a proper answer here and get points. – Noname Feb 8 '12 at 15:11
Because the wiki already answers all of that, and a 30 second search on google gives you everything you need to know, to be honest I was trying not to be mean and just say "Why don't you google it?", instead I was trying to give alternative info which maybe more useful in the end, or may not, either way, there's no point in answering the question per point directly, when, as mentioned, he can find this answer in a already well resourced area of the internet designed exactly for answering these types of questions. – SpYk3HH Feb 8 '12 at 15:31

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.