Re: [Tclhttpd-users] Problem with form data in threaded tclhttpd

[Colin M. <co...@ch...>]

On Thu, 2004-10-14 at 15:03, Colin McCormack wrote:
> On Thu, 2004-10-14 at 14:47, Gerald W. Lester wrote:

> > You need to ensure you use the Cookie calls that read them from the 
> > socket and not the uploaded directory.

> What about setting Cookies?  Cookie_Set is in error, because it stores
> cookies in a global.  This is definitely a bug.  It should store them in
> per-socket data.  I'll fix this now.

> Bottom line: if you're using Cookie_Set, the cookie is going to be
> corrupted sooner or later.

Looking at the code more closely, it seems that there are two interfaces
to set cookies - the ones in cookie.tcl (Cookie_GetSock, Cookie_Set and
Cookie_Save) and the ones in httpd.tcl (Httpd_SetCookie and
Httpd_RemoveCookies).

The second interface stores cookies per-socket, and whatever cookies are
stored with Httpd_SetCookie are inevitably sent to the browser.

The first interface stores cookies in the evil global variable Cookie,
and transfers them to the per-socket structure for sending only when
Cookie_Save is called.

The reason for this seems to be that some evaluation occurs in a slave
interpreter (evaluation of virtual host interactions, template
substitution, etc) and variables set there are slave-local, and so have
to be retrieved by the main interpreter before they can be used by the
Httpd_*Cookie versions.

At least, this seems to be the intent of the calls to Cookie_Save in
template.tcl and direct.tcl.

So, you seemingly can't (directly) use the Httpd_*Cookie interface from
a slave interpreter (template, direct, virtual?) and the code which
marshals the cookies to the browser can't know whether there's some
interpreter somewhere with values it should send back up the pipe to the
browser.

The more I look at this, the less clear it is :)
-- 
Colin McCormack <co...@ch...>