[Xitami] Possible race condition in Xitami's temporary files module

[Ewen McNeill]

In message <NEBBIJGPHKNLMOCJIHFJIEIDDAAA.dmitry@transnexus.com>, "Dmitry Isakbayev" writes:
>If there might be a bug in the way Xitami handles temporary files, how can
>we avoid using them?

If you can recompile Xitami for your platform, and are willing to spare
some memory, then you can change the constant that triggers when a LRWP
response will be spooled to disk.  The relevant compile time constant is
BIG_RESPONSE_LEN in xilrwp.c; the default setting is 16384, ie 16KB.  If
you make this, say, 1048576, then up to 1MB will be held in memory.  (If
you're server is busy and sending a lot of large responses, then
obviously you'll need to have a lot of memory available.)

>How can I learn more about the way Xitami uses temporary files and generates
>temporary file names?

Unfortunately the only real documentation for this internal stuff is the
source code.  Most of it is smthttpl.c IIRC, although the main control
logic is in smthttp.c, and the thread of execution pops in and out
between the two of them.

For LRWPs the main thing to remember is that once the response is
received from the LRWP program it's basically treated like a CGI
response.  (The same is true for filter responses BTW.)

The temporary files are created in smthttpl.c in the CGI case, and
xilrwp.c in the LRWP case.

Ewen

-- 
Ewen McNeill, Technical Consultant, iMatix Corporation  www.imatix.com