I think I have finally gotten to the bottom of this problem and have discovered that it is a NetWare and very possibly a Win32 issue as well. The return value of the call to apr_bucket_read() on line #1283 in protocol.c is compared against the macro APR_STATUS_IS_EAGAIN(). The problem for both NetWare and Win32 is that this macros is defined to test the rv against WSAEWOULDBLOCK rather than EWOULDBLOCK. Since the call to select() in apr_poll() actually returns EWOULDBLOCK for a pipe, the comparison fails, the EWOULDBLOCK is not handled and the entire read causes the browser return of "Premature end of script...". I will be submitting a NetWare patch for this problem as soon as I figure out what the right thing is to do. The Win32 platform should probably verify that this isn't an issue on their platform as well.
Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> Aaron Bannert <[EMAIL PROTECTED]> Tuesday, July 16, 2002 12:09:04 PM >>> On Tue, Jul 16, 2002 at 01:45:43PM -0400, Cliff Woolley wrote: > On Tue, 16 Jul 2002, Brad Nicholes wrote: > > > The problem with the MOD_CGI case is that it *doesn't* call > > pipe_bucket_read() with APR_BLOCK_READ. In fact it calls it with > > APR_NONBLOCK_READ which is what prompted the modification in the first > > place. If your analysis as to the definitions of APR_BLOCK_READ vs > > APR_NONBLOCK_READ is correct, then let me dig a little deeper in the > > code to figure out exactly why MOD_CGI is ultimately passing an > > APR_NONBLOCK_READ (unless somebody else already knows). What I do know > > is that if pipe_socket_read() is allowed to return with an EWOULDBLOCK > > error code, I end up with a browser response of "Premature end of > > script..." when in fact the data is there, just not at the right time. > > Justin's definition is correct as far as I'm aware. > > At the risk of stating the obvious: EWOULDBLOCK can only be returned in > APR_NONBLOCK_READ mode. Any caller that does a nonblocking read *must* > check for EWOULDBLOCK and loop or otherwise handle it. (A tight loop > doesn't make any sense, of course... if that's all you're going to do, use > APR_BLOCK_READ. APR_NONBLOCK_READ is only any good if you have other > stuff to do while waiting on more input.) Can someone please document with this level of detail in the header? Pleeease? :) -aaron
