[Twisted-web] web2 response.setCookie and request.getCookie shortcuts?

[glyph at divmod.com]

On Wed, 16 Nov 2005 16:22:19 -0800, David Reid <dreid at dreid.org> wrote:
>On Wed, 2005-11-16 at 17:42 -0500, Clark C. Evans wrote:
>> I'm still having fun with web2, it is such a huge improvment over
>> twisted.web and I'm absolutely thrilled with it.  However, I have
>> a few suggestions:

>You're in luck context is going away.  Far far away never to be seen again.
>As soon as an appropriate method for per-request data can be decided upon.

Do we have a list of use-cases somewhere that detail what "per-request data" is really a requirement?  Most places I've seen the context actually *used* in this manner it has been a disaster...

>>    2. I would love a request.getCookie('cookie-name') and
>>       response.setCookie('cookie-name','cookie-value', path = '/')
>>       helper; that adds the given cookie to the current list.
>
>I'm personally against polluting the request and response interfaces
>with this kind of stuff, in my opinion cookies are just headers, they
>shouldn't be special.  I wouldn't be opposed to higher level cookie
>management that presented a similar interface to both the client and the
>server developer, but I probably won't have any interest in writing
>it.

"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.

>>    3. Make the 'path' in the Cookie constructor and setCookie default
>>       to '/'.  Almost all of the time you want your cookies to be
>>       site-wide; adding path = '/' to each request adds a point of
>>       failure that makes the system less usable.
>
>I'm all for sane-defaults, but I'm not sure this is one.  I'll let foom
>decide.

I can speak from experience that cce's right; when you need a path, you know it, and you can pass it.  When you don't need a path, what you mean (in every case I've ever worked on) is /.