>>>>>I think MS missed the boat by using the mangled URL as alternative. Having the cookie stored within normal payload data would have been better - even down to allowing new, encrypted non-diskable cookies to be updated via HTTPS:// rest without breaking too much other architecture.
>>>>
>>>>Yes, this is exactly my point. If it would have been simply added in the query string, I would have been ok with that. At first, this is what I thought it was. Today, when I started to look at this, this is where I realized "Oh, is that really what the URL would look like".
>>>
>>>It looks like that on your browser (and may be visible in the same way in browser history) - but with https it's encrypted over the wire.
>>>In that respect I don't see it as being any less secure than cookies.
>>
>>true if only one-shot get/post are exchanged. Having cookie-like validation embedded in the payload would make it easier for REST/Ajax/Soap-style enhancements and lessen the pain of rewriting URLs and the ease serverside other stuff mentioned in thumbs down. The URL-mangling smells like premature optimization to me, unless you find some measurements citing massive gains.
>
>No gains really - just a transparent way of handling browsers that don't accept cookies. Embedding info in the payload may be better but harder to implement ?

Should have written "server side gains". My SWAG is that parsing can be done later or sometimes eliminated if not embedded in payload as it is delegated to routing in the mangled case.