4

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?
Improve this question
12
  • 7
    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
    Feb 7, 2012 at 18:54
  • 1
    Do you mean HTTP sessions?
    – jcmeloni
    Feb 7, 2012 at 18:55
  • 1
    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
    – TheTechGuy
    Feb 7, 2012 at 18:58
  • 1
    @YannisRizos: They're actually a part of the language definition itself?
    – FrustratedWithFormsDesigner
    Feb 7, 2012 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
    Feb 7, 2012 at 19:22

2 Answers 2

Reset to default
11

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.

Improve this answer
2
  • 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, 2012 at 20:06
  • 3
    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, 2012 at 20:16
-2

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.

Improve this answer
4
  • 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, 2012 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, 2012 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, 2012 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, 2012 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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