On Nov 17, 2005, at 6:57 AM, [EMAIL PROTECTED] wrote:
"content-length" and "connection" are just headers too: but the
code has to support them because they're in the RFC. Technically
speaking cookies aren't in the *same* RFC, but they do have a
standard of their own, rfc2109.
If there were multiple possible implementations of cookies, I'd say
there should be an adapter or something to keep it separate. Since
there is just the one way to do them, though, I think that it's
reasonable to treat the standards as merged, and just put the
methods on request to handle it. Pragmatically speaking cookies
are not an "optional" extension to HTTP/1.1.
Agreed, cookies are important. But, there's not just one possible
implementation. To start with, you've got three specs: netscape,
RFC2109, and RFC2965. I believe RFC2109 is essentially dead, and
shouldn't be cared about.
The code is there to parse and unparse all the cookie headers in both
Netscape and RFC2965 format, in the same way the code is there to
parse and unparse content-length. As cce indicated, you can directly
manipulate the parsed header representation. However, a higher-level
interface to cookies should be implemented.
However, this higher level implementation is not entirely trivial,
which is why I haven't done it yet. As an example of some of the non-
trivialities:
The Netscape cookie spec is insecure, often allowing random other
hosts on the internet to set cookies for your host(*). Uptake of the
RFC2965 spec is slow but gaining somewhat, and supporting it would be
a good move. It adds the ability to determine what host/path the
cookie was set for, so your application can verify that it isn't
getting cookies from an unexpected source. So, the high level
interface has to be more than a simple dictionary, it has to be
filterable by acceptable source host/port/path. But only when you
know you're talking to a client that supports RFC2965, which you can
tell because of various attributes. And when setting a cookie,
probably both Set-Cookie and Set-Cookie2 should be sent.
And stuff like that. All doable, and should be done, but to say
there's only one obvious way to do things is not exactly true. :)
(*): Most common example: User follows a link to http://
attacker.co.uk/. Said webpage makes a request in the background to
http://myserver.co.uk/ and I setup a new session and send back a
cookie with the session id: SID=1234. Attacker then sends back to
user a cookie: SID=1234, domain=.co.uk and redirects user to http://
myserver.co.uk/. Myserver gets the SID cookie, and uses that session.
Attacker now has access to all data available through user's session.
D'oh!
This was originally supposed to be prevented by the rule implemented
in browsers that you cannot set a prefix cookie for domains without a
dot, but that only protects domains which sell the second level
(e.g. .com, .org, .net).
James
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
