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

[Clark C. Evans]

Glyph,

On Thu, Nov 17, 2005 at 06:57:11AM -0500, glyph at divmod.com wrote:
| 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...

The system that I've layered over Twisted that I'm now porting to web2
is a request re-write system.  Basically, I view request handling as a
series of stages which _alter_ the request (I don't particularly like
the special status given to path segments in web2, btw; this should
be much higher-level logic).   For example:

  1.  I have one stage that converts /k=v/ path segments into cookie entries,
      so that user agents lacking a good cookie mechansim can still use
      the parts of my application that require "context" handling.

  2.  I have another stage that simply looks for a in-memory session object, 
      and attaches it to the request (for further down-stream stages).

  3.  My next stage does authentication; if a session object is already 
      marked authorized, this step is a no-op.  Otherwise, it handles
      one of many authentication protocols.

  4.  My application has many many ways to ask for the same thing, so
      my next stage simply 'canonicalizes' the request.  This replaces
      various short-cuts in the request's path segments or arguments
      with more tedious but explicit request.

  5.  Following is an 'authorization' step; which verifies that the
      current identity is allowed to perform the activity expressed
      by the (now canonicalized) request.

  6.  At this point; depending on many factors, my processing tree has
      many branches -- but at all stages, I'm passing around a request
      that is being continually modified to reflect the status of the
      request and where it goes next.  I use a state-transition graph to
      make sure that my request gets in the correct queue.

So, this is what I mean by per-request state.  Since each stage of
execution happens by a distinct Resource, a great deal of information
needs to be stored in the Request object (or what ever you want to call
it).   Now if a ClarkRequest extends a HttpRequest to add what I need,
so be it; right now my code is sloppy -- I just modify the request
object's dict.  Perhaps it is poor pratice; but with a decent regression
test it really isn't a problem at all.   I only have a handful of 
variables that are needed.

Anyway Glyph, I'm not quite certain I understand what you're saying or
recommending.  If you could detail a bit more, it would be wonderful.

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

You got to put it this stuff somewhere.  An adapter is quite a kludgy,
but I guess workable.  The current solution, however, is ugly.

| Pragmatically speaking cookies are not an "optional" extension to HTTP/1.1.

Hear! Hear!

Clark