[Zope3-dev] quoting cookies

[Steve Alexander]

> You think of this issue as "vertical";  in the absence of real use
> cases, I can only say "horizontal".  My real "line in the sand" is that
> I *don't* want any argument twiddling in the API of the request object;
> either it is configurable via component architecture mechanisms, or it
> isn't, but the policy choice should not be wired into the "mechanism"
> level.

I agree with that as a general principle.

Next, I want to see whether this particular case falls neatly under this 
general principle.


I contend that a component that is designed to work with an external 
system must be written to take account of these things:

* The shared conventions as to the cookie name

* The shared conventions as to the cookie value

The cookie value is the actual value that is meaningful to the systems, 
for example, an authentication token, which in turn is wrapped in an 
envelope of 'encoding'.

So, if I write a zope authentication component that is to work with an 
apache authentication component, the zope component must

* Use the cookie name that the apache component expects

* Save cookie values that the apache component can work with

* Encode the cookie values the way the apache component decodes them


For a particular cookie, the name and value and encoding of the cookie 
all depend on the same external system that I want to collaborate with.

I cannot see any reason to abstract the encoding of this cookie into a 
separate component. It actually makes things more difficult because I 
would need to configure the 'cookie encoding' component to work with my 
authentication component in a very particular and explicit way. Any 
other configuration of the 'cookie encoding' component for that 
particular cookie name will cause my authentication system to stop working.

I think this is a case where the scheme for cookie encoding is strongly 
tied to the component that needs to set the cookie. An 
AuthenticationServiceThatWorksWithApacheModWhatever component must 
control the cookie encoding if it is to reliably work with Apache's 
ModWhatever.

The particular encoding that ModWhatever expects can be written in to my 
zope authentication component. If this encoding scheme is more generally 
useful, it can be exported as a function.

I do not think that a separate 'cookie encoding policy' makes sense in 
this case.


Next, I'd like to consider the very common case of using Zope on its 
own, and not sharing cookies with other systems.

In this case, cookies should be encoded in some reasonable way, so that 
application programmers needn't be caught out by forgetting to encode a 
value that contains illegal characters.

Considering my description of the special case of sharing cookies with 
other systems, and the general case of using cookies only within zope, I 
feel that the API I suggested meets the needs I described.

   def setCookie(name, value, raw_value=False, **kw):
       'The cookie is encoded unless raw_value is True'

I think that the encoding scheme should be urlencode, as advised in the 
old cookies standard that Shane found.

Most cookies will be encoded by the default scheme, because they are 
only set and read within Zope. Some special cookies that are used by 
external systems will be set according to the requirements for 
interoperability with those external systems.

If anyone can think of a reason to want to customise the encoding scheme 
for regular zope->zope cookies, then I guess it makes sense to have that 
configured in zcml. However, that decision can be put off until someone 
actually has that requirement.



This is my understanding of the situation and the requirements. I've 
explained my thinking as clearly as I can. If any of the discussion 
above is incorrect or unrealistic, please point out exactly which parts 
are wrong.

--
Steve Alexander