Re: [rest-discuss] Can ReST replace cookies?
- Elliotte Harold <elharo@...> writes:
> Nic wrote:That is not true.
>> I've said this quite a lot recently.
>> I don't believe there's anything wrong with cookies.
>> What is wrong is using a cookie to manage a session with data hidden
>> in the session on the server side.
>> Using a cookie purely client side, or using a cookie like an extension
>> header in HTTP is perfectly ok.
> And I've replied to this quite recently too. It's not just about
> sessions. It's about boomarkability, linkability, e-mail-ability and
> more. A cookie is not a substitute for a URL.
> If http://www.example.com/shoppingcart shows me and you different
> resources when we load it into our respective browsers because we have
> different cookies, then cookies are violating the web architecture.
Here's an example of a resource that would not violate REST:
var arr = document.cookie.split(";");
for (var i = 0; i < arr.length; i++)
if (arr[i].indexOf("name=") == 0)
I think I remember Roy's thesis talking about client side state as
being specifically ok. Anyway, this doesn't break any caching or data
- Elliotte Harold wrote:
> One minor point. You write "The HTTP spec doesn't say we're allowed toActually it *is* the HTTP spec that is important here - in how it uses
> have URLs with usernames and passwords in them so we can't guarentee
> that they work anywhere else either."
> It's not really the HTTP spec that's relevant. It's the URI spec, RFC
> 3986. What that says is:
> The userinfo subcomponent may consist of a user name and, optionally,
> scheme-specific information about how to gain authorization to access
> the resource. The user information, if present, is followed by a
> commercial at-sign ("@") that delimits it from the host.
> userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
> Use of the format "user:password" in the userinfo field is
the URI spec in defining HTTP URIs (not all items that can be parts of a
valid URI can be used with all URI schemes).
The HTTP URI scheme is defined by RFC2616 as:
"http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
So not only does the HTTP spec not say you allowed to have usernames and
passwords in URIs, but actively prohibits it - such URIs do not match
the sheme-specific syntax.
Supporting such URIs as an extension has become less popular since they
were used in many spoofing attacks (IE stopping it entirely, Firefox
allowing it, but prompting you first).