Well, this global page URL is really a crok that must be fixed, frankly.
At the moment I don't remember why Doc_SetCookie cannot just call
Httpd_SetCookie instead of saving the cookie state in the page(set-cookie)
variable.
Oh yes, because it doesn't have access to the socket handle. You could get
this from the Url(sock) or env(HTTP_CHANNEL) variables, but these are globals
that
also suffer when you http::geturl back into yourself. So, you could modify
Doc_SetCookie to call Httpd_SetCookie, but you'd still need to wrap up
the http::geturl call with something that saved/restored Url(sock) or whatever
you were using in Doc_SetCookie.
The only good way to get a clean interpreter is to use threads, but that may
not jive with the rest of your application and C extensions.
>>>Ted Dunning said:
>
>
> We have run into an interesting snag using tclhttpd for a substantial system
> that we are about to release. We use tclhttpd 3.0.3 on tcl 8.3.1. We have
> http package version 2.3. Not surprisingly, this is an eleventh hour
> situation as all intriguing bugs ultimately are.
>
> The problem is that we have a tclhttpd server that does some work in a
> template file (essentially a .tml file). As part of its work, it needs to
> consult other servers via http transactions. Thus it calls http::geturl and
> goes on about using the resulting data.
>
> The problem occurs during the geturl call itself. The problem is especially
> evident if the URL we are accessing happens by accident or convenience to be
> on the server calling geturl itself. Of course, in a perfect world it
> shouldn't matter where this URL is, and I think that the only interesting
> aspect of this case is that a request comes in (from ourselves!) at just
> about the same time that geturl enters the event loop. In the case of the
> circular access, this is not an accident, but in general it could have been
> anybody who coincidently gave us that request.
>
> Anyway, when that other request comes in, the page array gets smashed and in
> particular page(set-cookie) gets unset. When we come back from geturl, we
> continue on our business and eventually the code in DocHandle (in doc.tcl)
> looks to see if we set a cookie and explodes because the set-cookie entry in
> page is not set. Of course, the .tml page in question NEVER EVEN knew about
> the existence page(set-cookie).
>
> Soooo.... the questions I have are (a) what to do in the short run and (b)
> how (or even whether) tclhttp should be changed to avoid this issue.
>
> a.1 we could save Url and page ourselves and restore them after the geturl
> call (ick!, but may work)
>
> a.2 I could hack doc.tcl not to unset page(set-cookie) and just hope that
> nothing else important is in Url and page. (This seems highly unlikely to
> work since the socket entry in Url is so crucial to anything working at all.
>
> a.3 I could possibly tell tclhttpd to use a separate thread for any URL that
> calls http::geturl. THis might decouple the namespaces enough to be safe.
> I wouldn't bet on this either. It might only fix the problem in tests and I
> would never know.
>
> a.4 ???
>
> on the long term issues,
>
> b.1 I thought that tclhttpd went to some trouble to use separate
> interpreters to avoid this sort of issue. What is happening here? Why
> isn't the name space for the recursive call separate from the namespace for
> the outer call?
>
> b.2 If the namespace used by a request is not intended to be separated from
> other requests, how can we separate different copies of page and Url for
> long running and overlapping requests?
>
> b.3 Is this just a problem for recursive calls, but not for calls that just
> happen to come in at the same time? If so, how can we know this for sure?
> Can we port the solution for simultaneous calls to the recursive case?
>
>
-- Brent Welch <[EMAIL PROTECTED]>
http://www.ajubasolutions.com
Scriptics changes to Ajuba Solutions
scriptics.com => ajubasolutions.com
