Coffeehouse Thread

16 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

HTTP being stateless, a curse or blessing?

Back to Forum: Coffeehouse
  • User profile image
    fanbaby

    Many FUD-ers like to point to the stateless nature of HTML/HTTP as the reason they would rather poke their eyes out with something, then code a webapp.

    Just this morning, I understood why this design decision of the creators of HTTP must have been the smartest/most lucky decision they have made.

    Any thoughts on that?

    I'll share my thoughts in a while....

  • User profile image
    Bas

    Since you've used your very first sentence to establish that you'll dismiss any opinion that differs from your own as FUD there's not much point in sharing thoughts and starting a discussion, is there?

  • User profile image
    Dr Herbie

    And of course HTTP was designed to be stateless because state was not needed for the original purpose (to link together static text documents).

    The real question is: if you were designing a WAN network system for today's usage patterns, would you make it stateless if you weren't restricted by speed\capacity?

    Herbie

     

  • User profile image
    evildictait​or

    HTTP 1.0 is definitely stateless, but HTTP 1.1 isn't (it just pretends to be) and HTTP/TLS sure as hell isn't (it also just pretends to be).

    The perversity of HTTP is that it already lives over a stateful connection (i.e. TCP or TLS), but just doesn't use the connection state for anything other than guaranteed delivery of in-order packets.

    To cope with the fact that web-authors actually want HTTP to be stateful, the Cookie: header had to be invented with all the cruft that goes with cookies, just in order to give HTTP back some of the state that it already had, but was busy throwing away.

    Stateful connections are expensive to create, maintain and use in terms of time and network resources compared with stateless connections, and HTTP just takes the state of the TCP/TLS connection and discards it, giving the protocol handler on top (your webserver) no choice but to implement a much worse method of maintaining state for your clients via cookies or session cookies on top of what should already be a stateful connection, bringing with it all the problems of implementing, storing and keeping cookies from being stolen or forged.

  • User profile image
    fanbaby

    Bas, I am sorry that my post offended you so that it procluded a discussion. It wasn't my intent.  Dr Herbie, yes I think that designing HTTP today I would still make it stateless.

     

    Hint: This thought came to me when I was sitting in a coffeeshop. Smiley

  • User profile image
    Dr Herbie

    You're not going to talk about how they process an order in the coffee shop are you? It's been done (pragmatic programmers, I think, can't recall where I've read it before).  Plus, the processing of coffee in a coffee shop does have state (the order), even if it is written on the side of the cup.

    Herbie

  • User profile image
    figuerres

    this is very much like some things i have said before.....

    HTTP and HTML as designed were for hyperlinking documents.

    what we are doing today is using them to create thin client / cross platform applications.

    IMHO we would be better served in this by the creation of a new set of standards that address this and not take on the baggage of the old HTTP / HTML design.

    the problems with this idea are multiple but not technically difficult, the main one is adoption, getting servers and clients in place to use it.

    i would possibly see if it could be added to web browsers but i would require that they render the content  based on a tight spec so that the problems we see in html / css would not carry over into the new spec.

    APPX://www.somedomain.com/App.Page

    or some thing like that.

  • User profile image
    wkempf

    @figuerres: HTTP and HTML aren't the problem. Neither is JavaScript. None of those are ideal for the creation of large applications, but they are usable. I wouldn't care to use them for large applications, but I could manage. No, the real issue is the browser, so why would you "possibly see if it could be added to web browsers"?

    As for the original question, like others have said we're stateless because there was no need for state for hyperlinked documents. We've struggled with the lack of state only when attempting to use the web for something it wasn't designed for. Some people have learned that a good deal can be done without state, and that many things should be stateless, but the reality is that not everything can be done in this stateless system.

  • User profile image
    Proton2

    What about " Web Sockets, an exciting specification that lets developers open bidirectional communication channels with back-end servers, thus enabling a level of "real-time" connectivity not previously available in Web applications."

    http://msdn.microsoft.com/en-us/magazine/hh335062.aspx

    I am a very experienced programmer, but have very little experience with web development. I specialize in scientific applications that don't currently touch the web. So please excuse my ignorance for all things html or http related.

  • User profile image
    fanbaby

    OK, my realization was that since HTTP is stateless, I can open an online app under one IP address, and continue working while switching IP addresses, say move to a different coffeshop Wink or go back home.

    Now, not sure if this is by design or just a lucky coincidence.

  • User profile image
    Bass

    Yup. Another thing the "stateless" nature of HTTP allows for is totally transparent caching, both at the client level and ISP level.

    Roy Fielding (one of the original authors of HTTP) discusses the behavior of HTTP-like protocols in his famous Ph.D. dissertation (which also defined REST, making it still possibly the best reference for writing RESTful web services).

    http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

  • User profile image
    Bass

    @figuerres:

    You can also just write one HTML page and have it AJAX call RESTful web services for needed data.

  • User profile image
    PerfectPhase

    I think HTTP connection should be stateless, it's a model that works well.  But at the same time we're seeing the rise of things like 'Comet' servers and the introduction of pure sockets into client side web, which means your free to roll your own statefull protocol and as @evildictaitor mentioned then you're not trying to reintroduce statefullness that to something that has gone out of its way to remove the statefullness of its underlying protocol. 

  • User profile image
    evildictait​or

    ,fanbaby wrote

    OK, my realization was that since HTTP is stateless, I can open an online app under one IP address, and continue working while switching IP addresses, say move to a different coffeshopWink or go back home.

    Actually that's not necessarily anything to do with stateful / stateless connections. For instance, you can be happily doing some online banking and then move to a different IP address and it'll still all just work, even though SSL is heavily stateful and each session is tied to your ip address. What happens is that the stateful connection gets torn down and then your browser renegotiates the stateful connection back to it's previous state when you get a new IP address - you the user don't notice anything funny happening other than perhaps a delay between when you click a link and when your browser actually manages to get there.

    Stateful doesn't necessarily mean that the end-user notices when the connection gets refreshed, it just means that refreshing the connection isn't the default behaviour after every action.

  • User profile image
    ESgarbi

    Talking about the advantages and disadvantages of HTTP, has anyone ever looked into SPDY? Or anything similar?

    http://www.chromium.org/spdy/spdy-whitepaper

  • User profile image
    evildictait​or

    ,ESgarbi wrote

    Talking about the advantages and disadvantages of HTTP, has anyone ever looked into SPDY? Or anything similar?

    http://www.chromium.org/spdy/spdy-whitepaper

    SPDY is pretty good actually. Basically it throws away pointless HTTP headers and does whole site compression with a one-time download of compressed dictionary. It also muxes lots of HTTP queries over the same TCP connection to massively reduce the overhead of a connection to the Internet.

    As to if anyone uses SPDY, the answer is yes. Both your browser and the server need to support it, so currently it's only Google Chrome connecting to (some) Google sites, but yes it works.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.