I changed from PHP to ASP.NET, now I’m working with webforms in a somewhat large company. I given some though and research to back my impressions on ASP.NET webforms and I came to the conclusion that Webforms is an attempt to make web applications easier to write for those who came from the "desktop programming" world.

But before shunning WebForms I decided to analyze the needs of the software we write and bumped on the issue of maintaining application states on the Web.

I understand that HTTP is a stateless protocol, and ASP.NET tries to simulate states with session variables , hiddenfields and viewstates, it is in my understanding also that all of the above cited have flaws and are not perfect ways to keep the state in my application, But I also understand the need to keep a state on my app.

Which raises the questions, is the HTTP really fit for this type of job (making applications that require state)? Are the tools currently available to webdevelopers enough? Are the new tools available with HTML5 effective at the job or are they just workarounds for the limitations to HTTP.

I love developing for the web, and I’m much more familiar with the web than with the desktop, I just been wondering about this HTTP statelessness thing for some time and i want to understand if I’m missing some point or if I’m right on my notions.

  • 2
    Mathew-Foscarini I was going to reply with the RFC 2616, But I do believe I understand your point: since the http is a request protocol mantaining states is no expected from it, but from the server and aplications should keep the states on the Server itself and not try to simulate with things such the infamous viewstate? is that it? Feb 15, 2013 at 20:41
  • 2
    @MathewFoscarini I think you are confusing something. Nothing in the question would fit HTML, and everything fits HTTP just fine.
    – user7043
    Feb 15, 2013 at 21:06
  • 2
    @delnan confusion is a normal state of mind for me.
    – Reactgular
    Feb 15, 2013 at 21:23
  • 1
    HTTP is a transfer protocol... other than the file transfer, what state is it supposed to be tracking? I agree with Matthew, you're confusing HTTP & HTML. Also, voting to close as its pretty silly to ask if its 'up to the task' on a web based system like this site. Feb 15, 2013 at 21:32
  • 2
    I think this comes down to the definition of "State". On the one had you could consider HTTP response codes as symbolic of the server's state but what of the application? Application state is not within the scope of the HTTP spec yet it is required by the majority of web applications.
    – NickSuperb
    Feb 15, 2013 at 21:32

3 Answers 3


The protocol may be stateless, but the app you write could maintain any state :)

  • 1
    I understand your point, but then aren't the current technologies below the task? I fell that Session variables are not fit to hold large objects and serializing them or "databasing" them is just unfit, Am i wrong? Feb 15, 2013 at 20:44
  • 1
    You're not wrong, but thank god we are smart enough to make the HTTP protocol enough for us. HTTP is also so simple that basically you can build anything you want on top of it: a brick is just a brick, but you can build houses and bridges with it. :) Talking about sessions... What about sessions implemented in Redis or other NoSQL databases? flask.pocoo.org/snippets/75 (and many others)
    – napolux
    Feb 15, 2013 at 20:55
  • 1
    @jonathan - There is localstorage available where you can save far more data than anything in cookies.
    – Rob
    Feb 15, 2013 at 21:11
  • @Rob But it's only for HTML5 / modern browsers...
    – napolux
    Feb 19, 2013 at 11:26
  • Well, he did say "modern applications".
    – Rob
    Feb 19, 2013 at 13:25

HTTP is certainly an older technology that has become quite ubiquitous as the web became so. As a result people are extending this technology to do many things now with modern web apps were it can appear the statelessness of HTTP is an issue. Hence you see a lot of conveniences like viewstates.

However it is also possible to code modern web apps in a stateless way and this is often preferred, RESTful web development is based on this idea. Many web API's that form the basis for modern web apps are truly stateless and should be. It is a different way to think and architect. Your needs may vary depending on what you are doing.

  • 6
    Stateless is also easier to scale and cache.
    – Reactgular
    Feb 15, 2013 at 21:05

Many protocols are stateless when you get down to the raw protocol layer. Statefulness is not the primary obstacle to Web Development. The primary obstacle is that HTTP by default is Sessionless. That is, by default a series of requests by a browser to a server are unrelated to each other.

We get around this by using cookies to denote a session. The ASP.NET server gives a cookie to the browser, who then returns it on subsequent request. Behind the scenes ASP.NET looks for that cookie and connects it to the Session that it has cached (assuming the session hasn't timed out).

From there, other data can be associated with the session and used to create a customized experience for each user. Web Servers and frameworks have become so good at this that rich clients can be built on top of the HTTP protocol. Case in point, Twitter clients use http for everything from retrieving a list of friends and tweets, to sending direct messages to other users. (I'm simplifying somewhat, there is a fully connected, TCP streaming protocol available through twitter, but for the most part, HTTP is at the core of everything.

HTML to a degree has reached its limits as an adequate display technology, but the HTML 5 standard along with JavaScript and CSS 3 have made it possible to create rich UIs that rival what's possible with native clients. In fact, HTML 5 has come so far, it is supported as a native technology for Windows 8 apps. With libraries such as JQuery for the client and NodeJS for the server, one can create an application that uses JavaScript for it's logic on the client and server and HTML for the display and pure HTTP for communications.

So, while the argument in the past that HTML/HTTP has reached its limit might have had some merit, it's just not the case anymore.


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