Is it possible (for webapps, that is)? Is it desirable? Current practice is to set up a session on the server side, then use the cookie (or a GET parameter or URL substring) as a key to associate individual HTTP requests with sessions.
There are some alternatives to cookies and URL rewriting — and even to server-side sessions themselves — that will work under many conditions:
- With HTTP authentication, the browser will resend credentials for each page, at the cost of a bit of extra HTTP overhead (the first time a page is viewed, there will be an extra exchange with the server, at least for Firefox). The user id can make an effective session key, and, in the case of authentication alone, can eliminate the need for sessions altogether.
- For multi-stage, choreographed processes, using a separate URL for each stage — in the best spirit of REST — eliminates the need to track the user’s progress as part of the session information, and also makes it easier for the user to bookmark a step halfway through the process and return to it later.
- It is also possible to stash temporary information in POST parameters: though some toolkits might balk, it is possible to have both GET and POST parameters to the same POST request, where the POST parameters won’t mess up the URL (though they will cause browser complaints with page reloading).
None of these is a perfect substitute for sessions, but I wonder if we haven’t used sessions and session variables a bit too much, just because toolkits have made them so easy to use. There’s also the philosophical problem that using any extra-URL technique (cookies, HTTP authentication, etc.) to customize a page violates the REST principle that n requests with the same URL should return the same object.
Who reading this has implemented a reasonably-complex webapp without using cookies or URL rewriting? What about a webapp that doesn’t use sessions at all?
Quoderat 
Don’t have a solution for you, but was curious why you want to live without cookies and url rewriting. Is there a compelling reason?
Cookies have serious privacy issues (and many users block them), while URL rewriting messes up bookmarks.
But why is it play to customize a page response when based on one part of the HTTP header (the user authentication) but not when based on another (the session ID in the cookie)?
The authentication information is voluntarily supplied by the user. Increasingly, cookies can be handled the same way — I turn them off by default in Firefox, and then grant them (sparingly) on a case-by-case basis to individual sites — but that’s a little beyond the average browser user right now.
“[…]violates the REST principle that n requests with the same URL should return the same object”
Hmm, I’m not exactly sure what you’re referring to there, but REST has no problem with GET requests to the same URL returning different things at different times, or as a function of information in the message itself (which is what the HTTP Vary header explicitly accomodates).
The solution is simple: use a single page which leaves the session on the client and interacts with the server using AJAX or similar technology.
The main problem with AJAX is that many implementations break bookmarks and the back button, though I understand that there are workarounds available.
Check out the comment system on http://cafe.elharo.com
No cookies and no URL rewriting
Well I personally find cookies a bit problematic but URL Rewriting is just wonderful things. Its kinda must for SEO and looks very neat.
The trouble with URL rewriting for session management is that bookmarks stop working (because your session is stale the next time you visit).
I love cookies / I HATE cookies.
Privacy aside, users on my site like to login as more than one user at the same time (They pay me so I cant say no). With session cookies this works fine in 2 seperate browsers, but if both are opened in the same browser instance (tabs or file|new) the cookies are shared and everything goes downhill from there…