RE: [Tclhttpd-users] Re: I need your advice, Cookies - global state - interrupted pages

[Shawn K. <sha...@ea...>]

Hi Folks --

What I would like to be able to do is to deliver an image file though a
request to it's URL (say /image.jpg) and have a template process the
comments in the file into a web page, along with copyright and header
information, and the original image -- Probably this is possible -- but the
problem I foresee is that generically processing a jpg file into a web page
is going to interfere with the requests to use it in a page.

What I really want is to assure that any request for a single image on my
site -- is presented with a specific title and description, credits and
copyright, and perhaps some keywords, and the anticipated header and footer,
with the real benefit being that adding an image to my site would be as
simple as adding the file in an appropriate directory - with comments.

Does anyone have any suggestions about good ways to go about this?

Thanks

Shawn

-----Original Message-----
From: tcl...@li...
[mailto:tcl...@li...]On Behalf Of Brent
Welch
Sent: Monday, October 18, 2004 7:00 PM
To: Colin McCormack
Cc: tcl...@li...
Subject: [Tclhttpd-users] Re: I need your advice, Cookies - global state
- interrupted pages


The Doc modules and template handlers make the assumption that
page processing runs to completion, so they use global variables instead
of per-connection state.  This has obvious problems, and I apologize
for that state of affairs.  But, for simple template processing with
a non-threaded interpreter and no calls to vwait, it has worked
reliably for me.

If you use the threaded interpreter, then the connection state is
copied into the interp of the worker thread, and so that model should
continue to work OK.  However, anything that relies on the env()
global variable could get into trouble.  The ncgi module, however,
is explicitly initialized by TclHttpd and that doesn't use the env()
array.  If you are calling ncgi::reset yourself, then you should
dig out the per-connection query string instead of letting ncgi
fish it out of the environment.  Look at the existing calls to
ncgi::reset to see what I mean.

The Thread layer in TclHttpd doesn't explicitly set up the ncgi
module, so if you did that yourself, you might have missed this
subtle point.

About cookies, they have a similar issue of no easily obtainable
connection state, hence the evil global.

I really think the best way to deal with this is if you are
doing requests that get interrupted and so violate the
"run-to-completion" event semantics, then you move those
into worker threads using the threaded version.  Then you can
use a per-thread interpreter and not worry about sharing
globals.  The only global you must avoid is env().

>>>Colin McCormack said:
 > Hi Brent,
 >
 > Some code in cookie.tcl relies on the global Cookie array to stage
 > cookie data before passing it to Httpd_ files which actually send the
 > cookies.
 >
 > The procs in question are called by template and direct modules.
 >
 > I think that the intention is to allow data to be passed back to the
 > main interpreter when it has been set in a slave interpreter, because
 > that's the only reason I can imagine for them to be set up and called
 > the way they are.
 >
 > There's a bug in this approach, because the data can be corrupted by a
 > page interrupting another page.
 >
 > (Incidentally, there's another bug hiding in the way we use global page
 > to pass back the dynamic status of generated templates ... although this
 > is probably less dangerous than cookies being overwritten by interloping
 > pages.)
 >
 > Perhaps this is the cause of "[760802] data(mime,cookies) - Cookie_Get
 > out of sync" at http://snipurl.com/9t7n ... I don't know.
 >
 > Can you help me by telling me what you understand to be the purpose of
 > the Cookie_* setting and getting commands, so I can try to change the
 > implementation to avoid the race, by using the data array to store
 > cookies.  I would have done this already, but I noticed that the Httpd_
 > cookie stuff already does it, and am puzzled by there being two ways to
 > do (almost) the same thing.
 >
 > Also, should one of the interfaces be deprecated, or is there some
 > subtle difference between them, which eludes me?  This is quite
 > possible.
 >
 > More generally ... would it be worth adding an optional quasi-semaphore
 > to the Httpd protocol stack which just increments a global on receipt of
 > a protocol request and decrements it on completion of processing, to
 > detect interleaving of requests?  It'd have to take account of
 > Suspend/Resume too.  If the counter ever had a value other than 0 or 1,
 > it would signal a potential race, which could be logged.
 >
 > Such a facility could be used for early detection of some of the race
 > conditions we're seeing reported.
 > --
 > Colin McCormack <co...@ch...>
 >

--
Brent Welch
Software Architect, Panasas Inc
Delivering the premier storage system for scalable Linux clusters

www.panasas.com
we...@pa...




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
TclHttpd-users mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tclhttpd-users