views:

1192

answers:

3

I have done a bit of testing on this myself (During the server side processing of a DWR Framework Ajax request handler to be exact) and it seems you CAN successfully manipulate cookies, but this goes against much that I have read on Ajax best practices and how browsers interpret the response from an XmlHttpRequest. Note I have tested on:

  • IE 6 and 7
  • Firefox 2 and 3
  • Safari

and in all cases standard cookie operations on the HttpServletResponse object during Ajax request handling were correctly interpreted by the browser, but I would like to know if it best practice to push the cookie manipulation to the client side, or if this (much cleaner) server side cookie handling can be trusted.

I would welcome answers both specific to the DWR Framework and Ajax in general.

A: 

Manipulating cookies on the client side is rather the opposite of "best practice". And it shouldn't be necessary, either. HttpOnly cookies weren't introduced for nothing.

Thomas
He's not manipulating cookies on the client; he's manipulating them on the server in response to an Ajax request. In any case, client-side cookie manipulation is not generally considered harmful as long as it degrades gracefully when JS is disabled or unsupported.
Ryan Grove
+6  A: 

XMLHttpRequest always uses the Web Browser's connection framework. This is a requirement for AJAX programs to work correctly as the user would get logged out if the XHR object lacked access to the browser's cookie pool.

It's theoretically possible for a web browser to simply share session cookies without using the browser's connection framework, but this has never (to my knowledge) happened in practice. Even the Flash plugin uses the Web Browser's connections.

Thus the end result is that it IS safe to manipulate cookies via AJAX. Just keep in mind that the AJAX call might never happen. They are not guaranteed events, so don't count on them.

64BitBob
Thanks, despite the small amount differing opinions, this makes the most sense given my own test results, the votes, and general best practices around centralizing business logic on the server side.
Pete
My pleasure. I have also done quite a bit of research in this area while creating a mutliplayer game API for Flash and Javascript. Thanks to the 2 connection limit imposed by the HTTP RFC, it quickly became apparent that I was using the browser's connections. The cookies confirmed this info.
64BitBob
+1  A: 

In the context of DWR it may not be "safe".

From reading the DWR site it says:

It is important that you treat the HTTP request and response as read-only. While HTTP headers might get through OK, there is a good chance that some browsers will ignore them.

I've taken this to mean that setting cookies or request attributes is a no-no.
Saying that, I have code which does set request attributes (code I wrote before I read that page) and it appears to work fine (apart from deleting cookies which I mentioned in my comment above).

Darren Greaves