Re: Fastcgi and cookies

Nigel Metheringham (Nigel.Metheringham@theplanet.net)
Tue, 18 Jun 1996 10:59:22 +0100

Message-Id: <m0uVxZC-0006YHC@dingo.theplanet.co.uk>
To: Mark Brown <mbrown@openmarket.com>
From: Nigel Metheringham <Nigel.Metheringham@theplanet.net>
Subject: Re: Fastcgi and cookies 
In-Reply-To: Your message of "Mon, 17 Jun 1996 15:52:00 EDT."
             <199606171952.PAA20884@breckenridge.openmarket.com> 
Date: Tue, 18 Jun 1996 10:59:22 +0100

[the subject is wrong now... but since things are getting wide 
ranging I have left it alone :-( ]

} Speaking of performance, a message went by yesterday on the Apache
} list reporting a serious performance bug in mod_fastcgi.  The select
} call in mod_fastcgi is specified to use a zero timeout; a much
} longer timeout (perhaps infinite) would be appropriate.
} As soon as we have a good patch it will go to this list.

I just had a look at that.
You are spinning with a zero timeout in a loop, which seems silly!  
You could make the timeout a NULL pointer to give an infinite timeout 
and have exactly the same result.

Alternatively, you could make the stuff work with a real timeout 
which when expired the modules assumes things are wrong.

I am testing with a NULL timeout now - just building up apache 1.1b4.


}     However the state keeping is falling apart.  If a cookie is passed in, 
}     it appears to get to the program through the environment (tested by 
}     dumping the environment).  However cookie data generated in the 
}     header passed out by the script does not appear to be "taken" by the 
}     browser - so may not be getting there at all!
} 
} Various folks have reported bad interactions between existing Perl
} CGI packages and FastCGI.  I'd be interested in knowing what packages
} people have had success with.

There is definitely state being kept within the CGI package - and its 
embarassing - you can call up the script and see the last users 
username and passcode neatly filled in for you!  Fortunately we use 
one time pass codes... but obviously state is being kept which should 
not be.
I was (with this problem) already using the delete_all method at the 
end of the loop *and* undefing the parent variable, but still some 
state is being hidden somewhere.  I am building some smaller test 
code to work on now.

Its a shame that the CGI package doesnot work right at present - its 
very widely used and a nice piece of work.

Also I am *very* unhappy about the perl build process - making a new 
perl for fastcgi is a real bitch!  Particularly as your build process 
did not work on our Sun (SunOS 4.1.3 patches) system so I had to do a 
lot of hacking around, then to find that the extra cflags broke the 
Configure test programs, so other things didn't work (ie no signal 
names!).  I eventually configured as normal (no fastcgi changes), 
then edited config.sh (at the prompt) and added the cflags, ldflags & 
libs entries, and changed the stdio settigs (std stdio and base etc 
entries - all together in config.sh) to undef.  This worked and 
tested OK.

Would it not be possible to:-
  1. Just have an FCGI module, leaving the main perl stdio alone.
  2. Have a modified CGI module which uses the FCGI input routines.
  3. State that all output must go via a different file descriptor 
which
     is handled by FCGI.  You could then attach STDOUT to that 
descriptor
     at the top of the program if you wished.

Building a new perl with non-standard build process is a pain, and I 
have to admit I have installed it under a different name since I 
don't really trust it :-)

} You can diagnose the problem using "tcpdump" or similar relay program,
} or by simply doing a telnet to the server.  At least you'll be
} able to tell whether or not the Perl program is returning
} a cookie, and thus narrow down the problem.

Its well worth looking at a new copy of lynx - you can feed form data 
into it and make it dump the whole response from the server.  Putting 
POST data in by telnet for a complex form is not my idea of fun!  And 
converting tcpdump to readable output requires more hacking!

[For the netscape addicted... Lynx is a text mode browser, very good, 
current version is 2.5, look at:-
	http://www.nyu.edu/pages/wsn/subir/lynx.html
]

	Nigel.



-- 
[ Nigel.Metheringham@theplanet.net   - Unix Applications Engineer ]
[ *Views expressed here are personal and not supported by PLAnet* ]
[ PLAnet Online : The White House          Tel : +44 113 251 6012 ]
[ Melbourne Street, Leeds LS2 7PS UK.      Fax : +44 113 2345656  ]