AJAX: what’s a session?

As I mentioned here, my concern about the buzz surrounding AJAX is not what’s being said but what isn’t being said.

One question I’ve got nagging me, which I’ve yet to see serious discussion of, is the that of AJAX and sessions / state. I guess either no one is thinking about it or it’s got brushed under the carpet of “implementation detail”. The furthest I’ve seen seen the discussion go in this direction is Diego blogging on ajax. That said Joshua Eichorn did a great job of hinting at the issues with his memento demo - move the pictures around then hit your browser’s “reload”.

From where I stand AJAX redefines the notion of state in web applications - the “new session” exists for a user for as long as they keep the current web page running. Session data is being “persisted” locally on the client, in memory in Javascript variables.

Of course it’s not that simple and Diego hits the right term, in talking about the “the thin-fat client”.

Background

The web is inherently stateless. That is HTTP is stateless - once a web server has delivered it’s response to you, the connection is closed and it no longer cares you exist.

Of course that’s not great if you want your web app to recognize returning users, either for the purpose of displaying a “Welcome back Joe Bloggs” message or implementing functionality like a shopping cart. To get round this inherent statelessness, you need to build things on top of HTTP, which Netscape did somewhere around 1997 with their cookie spec.

With cookies it is possible to store data “permanently” on a given client, tied to the domain that issued the cookie. The cookie data is then exposed to the domain that issued it, for all future requests, until the cookie expires.

Of course cookies aren’t suitable for all data. If it’s sensitive information such as a credit card number or a password, that data is at risk to anyone with access to the client filesystem or anyone able to listen in on the conversation between the client and the server (i.e. when using HTTP not HTTPS). It’s also a bad idea to store large quanties of data in cookies, as it’s going to eat bandwidth and resources on the client and server. And these days users often work with many different client computers, from their home PC, their desktop at work, from an Internet cafe or even mobile devices. Unfortunately cookies don’t travel as well as users do.

So some of this data you want to keep on the server and the natural next step was using cookies to implement the notion of “sessions” - send a cookie containing a unique identifier for a given user during a given “visit” to a web site and the server can retrieve data specific to that user without exposing it to the world. Cookies aren’t the only way to implement sessions. Another approach is attaching an ID to all “internal” URLs but this introduces greater security risks. It’s also common to use hidden form fields in POST requests, sometimes for short-term “state” for a multi page form or “wizard” (see Application Controller) or, in more extreme form, ASP.NET’s view state. And there are more obscure ways to track sessions. But cookies remain the most popular compromise for solving this problem in general, most web based solutions, from PHP to J2EE implementations, providing default solutions based on cookies.

Persistance on the Server

While not directly related to AJAX, thinking about what happens on the server is also important, at least when it comes to implementation time. I’ve already had questions along this line regarding JPSpan and it’s clear what’s obvious to me isn’t obvious to everyone.

This is an itchy subject in web applications. Once you’ve started using sessions, you need to live with the consequences. When you’ve only got one web server, storing user session data is no problem. But crank up the traffic volume and you start wanting to add more servers to cope with it, balancing requests between them, scaling horizontally. Suddenly you have a problem in providing all servers access to the session data.

The solution to this depends on who you ask and the arguments are often conflicting.

The J2EE crowd, for example, bought the notion that databases == evil (or perhaps database vendors == evil - independence baby!). Somehow that’s extended to database == bottleneck == can’t scale.

Meanwhile Rasmus describes shared nothing and PHP;

PHP encourages you to push scalability issues to the layers that require it. If you need a shared datastore, use a database that supports replication and can scale to the levels you need. If you need to load balance requests or distribute certain requests to certain servers, use a front end load balancer that supports this. By avoiding a central controlling process, PHP avoids being the bottleneck in the system. This is the defining characteristic that separates PHP from what people commonly refer to as application servers.

Which could be read as “pick a decent db vendor and use the features you paid for”.

The two key issues, as I see them, for scaling horizontally are efficiency and transparency. If replication traffic floods the local network your servers run on, grinding it to a halt that’s clearly bad news - now the network has to scale vertically. Meanwhile it should be possible to tap into a back end “farm” from your web application without having to significantly modify code, or even spend vast effort in design the code to scale in the first place.

So my personal bias is leaving this to filesystem or database vendors to get right. The technology is mature, it’s alot easier to tap into scalability in these layers without massive effort in code design and, perhaps most of all, the future of people like these guys depends on solving this one.

Alternatively you can take a gut level view. If you want to build something that works, talk to techies with a solid understanding of networks and, better yet, those who happen fluent in Perl and just coincidentally play a part in defining the spec we rely on and keep returning to bite later on.

Obscure side note: is HTTP subversive by design? Perhaps the design concerns were simply “This must scale” but HTTP keeps dropping reminders that the web is not there to be centralized. Attended a keynote by Roy Fielding where he remarked that he knew the work he was doing on Apache would help protect the HTTP spec. from vendors. Whether that’s in retrospect I don’t know (should have asked) but if you like the word “Open”, Roy is one person to thank.

AJAX and State

Back on track after rambling, so what’s the impact of AJAX on sessions and state in web application? Personally don’t have answers, only more thoughts and questions.

As already said, as I see it, AJAX redefines the notion of what a session is in web applications. The state of a given user’s session can be maintained client side in Javascript and will remain there so long as they don’t click reload.

Data that you “check out” from the server via AJAX resides locally and can be changed locally without the servers awareness, until you “commit” it back to the server.

A user may change their “personal preferences” in your application but this information is finally only transmitted to the server, via AJAX, on Unload and recalled on the next reload.

Technically that means we can now ditch cookies and server-side session implementations and the server side can be just as stateless as HTTP. In practice, common sense suggests it’s not so simple and this is more a matter of drawing lines in the right places, of which data should be preserved where.

Implementation Detail

Resorting finally to bullet points;

Data Loss?
User has locally modified data

• User’s browser crashes - session data is lost. Seems like a good reason to keep those server-side sessions
• The network / server is down and updates can be no longer sent. Use cookies as backup until data can be sent? Security implications of that?
• Can we send data reliably? Are we sure it got there? HTTLR?

When to transmit changes?

• Do we want fine grained updates? Transmit the change as the user makes it. What’s the network cost? Or should we send a bunch of changes together, e.g. onUnload? See Point 9.
• Do we transmit changes automatically, without bothering the user? Or do we give them a “Save” button, like Word, and warn them of potential data loss onUnload? Ever thought how 1990’s that Save button is?

Difficient Runtimes
Are we heading for nightmares with Javascript garbage collection? Certainly keeping 100,000 records on the client is going to be a bad idea.

Concurrency

Users A and B are both modifying record X. User B “saves” then User A “saves”, overwriting User B’s changes.

Technically this is already problem with todays web apps but think the “immediacy” data exchange with AJAX compounds the problem. It’s notiously difficult to implement “locking” mechanisms effectively over the web, given statelessness and inherent “brokeness”. Best attempt I’ve seen is Dokuwiki, which users timed locks to prevent multiple users editing together.

Authentication

Somehow HTTP Basic Authentication appeals most to me as something you can implement transparently, vs. “inline” authentication based on something like cookies / server sessions or POST data.

Problem is there’s pretty much no access to the browsers HTTP basuc auth APIs with XMLHttpRequest, other than two arguments to the open method;

[code lang=”javascript”]
void open ( AUTF8String method , AUTF8String url , boolean async , AString user , AString password )
[/code]

My own experiments with them suggest they’re better left unused - farm this problem off to the browser and rely on the HTTP status codes.

What else?

…

Back Button Expectation Gaps

I think it’s been pointed out so much that nobody can miss one of AJAX’s apparent faults - the back button and it’s unexpected results for the user. There is an expectation gap of sorts between AJAX, users and browsers.

What does this mean for a hypothetical one page Web Application? Pressing the back button, and seeing everything fall apart is not something a user expects. There’s a gap in expectations between browsers and AJAX. Browsers are designed around the concept of using hyperlinks to browse from page to page - a multipage environment. But AJAX flows against that concept, existing to update a user’s current page, not to refresh the entire page and add it to browser history. Does the browser care about this? Well, seeing the results of back button usage - it doesn’t appear to…

Add the related expectation gap between users and an Ajaxified web page and you see an obstacle taking shape. Users are not particularly familiar with AJAX, many will never have heard the term, nor witnessed it in action on a large scale. As far as they are concerned, that button in the corner of their browser labelled “Back” will reverse any action they make. But such an assumption can fail when pitted against an ajaxified webpage or web application.

Rands states a case for making the back button optional in his thought provoking The Web Application Leap, based on two ideas:

Stop thinking of a web application as a collection of pages.

The back button is not a bug in Ajax, it’s a flaw in the browser metaphor.

It’s difficult to see back buttons vanishing at any stage, and it is possible under many circumstances to work around the issues it raises. But the back button is not an “undo” button… Who do we look to for a resolution, browser developers or AJAX users?

Synchronous Requests == BAD

This is one point where I agree strongly with the name AJAX - remember what that first letter stands for…

To grasp why, it’s worth seeing some examples and discussing which I’ve attmpted before here.

In essence, when you make a synchronous call with XMLHttpRequest, everything else stops and waits for the request to complete. And that means everything - even any intervals you’ve set. You can’t even abort() the request via the readyStateChange property (don’t believe me? try and watch a [browser dependent] crash…).

In other words submitting a synchronous request puts you at the mercy of the network and the server you’re making the request to. While developing on localhost, you’ll probably be unaware of this and living under the illusion that synchronous requests are just fine. But on a live site, if the server happens to get Slashdotted, while you’re busy SJAXing, expect a very long wait and a dead browser - to an end user, particular when using IE, it looks like it’s crashed (if I remember right IE does eventually recover but only after about 5 minutes).

To really get a feel for this you need to see it in action, which I’ll do with the help of a simple Python HTTP server that only accepts on request at a time, then goes into a sleep for 10 seconds before serving the next request. Any other incoming requests have to wait until the server is free to continue working. This sort-of-simulates a web server that’s got too much work to do.

Note if you’re using Windows and don’t have Python installed, do so - it’s completely painless. Make sure you add the python executable to your PATH (i.e. Start > Control Panel > (Administration) > System > Advanced > Environment Variables and add C:\Python24\ at the end of the PATH variable).

The code for the server is simply;

[code lang=”python”]
#!/usr/bin/python
# minimal web server. serves files relative to the
# current directory.
#
# See: http://effbot.org/librarybook/simplehttpserver.htm
# http://docs.python.org/lib/module-SimpleHTTPServer.html
# http://docs.python.org/lib/module-SocketServer.html
#
# IMPORTANT QUOTE:
# “[the basic SocketServer implementations] process requests
# synchronously; each request must be completed before the
# next request can be started.”

import SimpleHTTPServer
import SocketServer
import time;

PORT = 8000

class MyHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):
def do_GET(self):
SimpleHTTPServer.SimpleHTTPRequestHandler.do_GET(self)
# Go to sleep for 10 secs after serving request
time.sleep(10);

httpd = SocketServer.TCPServer((”", PORT), MyHandler)

print “serving at port”, PORT
httpd.serve_forever()
[/code]

Put this in some directory on your filesystem, in a file named server.py. Now add another file called response.txt to the same directory, containing simply;

[code]
Hello World!
[/code]

Finally add a third file called ajax.html to the same directory, containing the following;

[code lang=”xml”]

Do it!


[/code]

With that done, you can now fire up the server script - run server.py. For Windows users that’s something like;

[code]
C:\path\to\server.py
[/code]

If you put the python executable in your path or;

[code]
C:\Python24\python.exe C:\path\to\server.py
[/code]

if you didn’t.

The server is now listening on port 8000 so you should be able to access from your browser via the URL http://localhost:8000.

Follow the link to the ajax.html. Now click “doIt” a few times and see what happens - sometimes you’ll get a quick response (an alert that says “Hello World!”). Other times you’ll get a longish wait, during which your browser will be hung up. Now imagine users starting to fidget…

Then, to really see why synchronous requests are a bad idea, try running Apache Benchmark at the same time (it’s provided with Apache 2 as an executable for Windows users) e.g. from a DOS box;

[code]
C:\Progra~1\Apache2\utils\ab.exe -n 50 http://localhost:8000/response.txt
[/code]

Now try clicking on that “doIt” link a few times. Is this something you really want your users to experience?

Otherwise, another thing to try to really grasp the difference between synchronous and asynchronous requests is watching code execute with Venkman.

The bottom line here is remembering the Internet has instability built in - it’s a network you don’t control and can (and will) vary in percieved responsiveness, like when they release the verdict on Michael Jackson, complete with video.

The only two possible exceptions I’d make to this are for an Intranet application, where the end users are in shouting distance, or perhaps in the special case of a sychronous multipart requests (work work only in Mozilla anyway) - see this Sync Multipart demo and notice how the browser “recovers” while the request is still in progress.

So, to repeat, Synchronous Requests == BAD.

A Grumpier Ajaxian

Figured I’d jump in on this blog, as I’ve got itches to scratch.

I’m the author of JPSpan, a toolkit for hooking up PHP and Javascript via XMLHttpRequest. The ideas behind JPSpan were originally conceived back in April 2004, as blogged here and the first release announced in September 2004, albeit under a different name. So while I don’t have the same stomping rights as Brent Ashley, author or JSRS, figure I’m a “pre-Ajaxian”, with mixed feelings about the hype surrounding the term, although JPSpan itself more or less fits into Jesse Ruderman’s definition or AJAX.

That’s not to say I’m going to get stuck on whether the term or the hype is good or bad. Think the end effect is positive - what AJAX potentially enables is “better” web applications for end users and with so many eyes and brains now focused on solving AJAX related problems, the odds of solving them are good.

Where I do want to get grumpy is on more practical matters. What bothers me, amongst all the talk going on about AJAX right now, is I see very little discussion of what are, to me, the most critical issues.

Alex Bosworth raised a number of good points in AJAX mistakes but found myself wanting to insert some at the top of the list;

1. Assuming the network is reliable: have you seen what a synchronous XMLHttpRequest does to IE when you have high network latency? The Sourceforge web services have periods of extreme latency - next time you happen to notice it, try the sync requests here. And what about async requests that vanish into the void? Data loss?
2. Leaving Security as an Afterthought: many of the the AJAX examples (like Google Suggest) and toolkits (JPSpan included) are delivering server responses in the form of eval()-able Javascript. The technical reasons for doing this are good but what’s the implications here for XSS? More generally, have we asked enough questions about security issues with AJAX? Sam Ruby was on the case here, as Alex Bosworth highlighted, and this was an obscure enough issue to later catch out many you would expect to know better. What else is lurking? AJAX implies you’ll likely be storing some degree of (traditionally) server-side data in Javascript variables on the client. How do you feel about this?
   
var ccNum = AJAX.getCreditCardNumber(userId);

3. Regarding Javascript as a robust application development platform: Javascript today is about where it should have been when the term DHTML was coined. The Javascript implementations across the current versions Internet Explorer, Mozilla, Safari / Konqueror and Opera are more or less solid and and similar enough to have taken the pain out of DHTML. That’s not to say it’s a bad language as a concept - it isn’t. And when I look at the source of prototype, I’m impressed - love the way Try.these() works.

   But AJAX introduces a whole new set of demands and issues, such as garbage collection , perhaps features like threading (comment from Anjan Bachuu nails it), libraries for common problems and a greater need for optimizing and profiling. Mozilla is definitely leading the field here with spidermonkey and Venkman, perhaps because they’ve committed themselves to Javascript with the whole XUL / XPCOM deal but the other camp has this to say;

   “JScript was designed for simple scripts on simple web pages, not large-scale software.”

   The high level view is probably don’t expect significant AJAX development to deliver on time right now.

Anyway - that’s a hint at where I’m coming from. Will be aiming to push out some more constructive grumpiness over time.

Summit inspired overview of Ajax

Need some light Sunday afternoon reading? Or, new to ajax and befuddled as to what this all means? Then this might be the article for you. Derek Powazek attended the recent Ajax Summit put on by O’Reilly and Adaptive Path, and shares some of his thoughts and insights about what this all means.

Link

What’s Ajax? For the geeks, it’s Asynchronous JavaScript + XML. For the rest of us, it’s a whole new way of looking at the web. Really.
. . .

Ajax, and the pile of techniques and technologies that get lumped in with it, are all about breaking that page-by-page web experience into smaller chunks. If the traditional web was letter writing, Ajax is instant messaging.

Things To _Not_ Do With Your Ajax Foo

Alex Bosworth of sourcelabs.com has recently posted a list 10 common ajax mistakes. It’s a well thought out set (albeit some are more corner cases than others) of usability issues to keep an eye on as your building your next ajax app.
A big part of of ajax’s alure is the increased usability you can craft with it. But this is all for nought if your new-fangled interface doesn’t give the user visual cues as to whats going on, or if you take each new page as an opportunity to reinvent standard UI elements.

Ajax is an awesome technology that is driving a new generation of web apps, from maps.google.com to colr.org to backpackit.com. But Ajax is also a dangerous technology for web developers, its power introduces a huge amount of UI problems as well as server side state problems and server load problems.

Link
Link to a backpackit version (contact him and you can add your own to this version)

Ajax Bloggers Wanted!

We’ve just reached our 100th RSS subscriber here at Ajax Blog!

Unfortunately, the few contributors to this site get busy every once in a while (work, side-projects, star wars, etc, etc).

So, we’re looking for one or two additional Ajax Bloggers who can post interesting material (links, articles, resources, etc) on Ajax!

As an Ajax Blog contributor, you’ll reach an ever-growing audience of web professionals interested in developing & delivering rich web experiences.

It only takes 5 minutes to signup and begin blogging for Ajax Blog, too! Just head on over to NinerNiner.com, then hit the Signup page.

The beta password is: niner

Shhhhh! It’s such a difficult password to guess, please don’t tell anyone or we’ll be mobbed!

If you have any questions about writing for Niner Niner, shoot me an email at: shantibraford @ gmail

Have a great Star Wars weekend, if you’re into that sort-of geeky thing!

A Simpler Ajax Path?

Matthew Eernisse has posted a tutorial titled A Simpler Ajax Path over at OnLamp.com.

While the article is a great resource for people brand new to “Ajax” or the XmlHttpRequest object + server-side magic, I don’t think it’ll be especially useful for building large-scale Ajax applications with tight server-side integration.

I honestly haven’t played too much with Ruby on Rails + Ajax, but from everything I hear, the integration is mindblowing.

David HH on Ajaxing the Rails:

It’s basically no harder to make something Ajaxed than it is not to, which means that the decision is based on whether its a good fit for the user interface — not on whether we have time to another Ajax project.

PHP has some good Ajax frameworks as well, though nothing as earthshatteringly simple as Rails + Ajax … at least for the time being.

AJAX Patterns Wiki

Nice ever-growing wiki on Ajax Patterns:

… an in-progress collection of AJAX patterns being collected and discovered by Michael Mahemoff (http://mahemoff.com).

Of course, it’s a Wiki, so anyone can contribute and make it better!

Background: Why Ajax patterns?

XMLHttpRequest Tracing for Ajax Debugging

Just came across this piece on debugging your Ajax scripts.

Julien Couvreur has created a Greasemonkey script to help trace XmlHttpReq calls.

Here’s a screenshot:

Very cool indeed. Link

Next Page »