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?
