On Nov 17, 2005, at 6:57 AM, glyph@divmod.com 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