Date: Wed, 24 Sep 1997 22:15:39 -0400 (EDT) From: Stanley Gambarin <firstname.lastname@example.org> To: Jim Boutcher <email@example.com> Subject: Re: Appclass/Virtual Host Configuration Problem In-Reply-To: <199709242139.QAA27791@oasis.novia.net> Message-Id: <Pine.GSO.3.96.970924214935.20884A-100000@csa> On Wed, 24 Sep 1997, Jim Boutcher wrote: > It's just with fastcgi.. I created a symbolic link to the cgi-bin directory > (where the fast cgi apps are located).. I configured Apache to > followsymlinks, and I have absolutely no problems accessing regular > cgi's/programs using the symbolic link.. But, when I access the fastcgi > application, I get an error, and the error log states something along the > lines of: > > No AppClass directive for > /usr/local/etc/httpd/symboliclinktocgidir/fastcgiapp.fcgi > I don't know why I had not thought of this first... probably because I was too busy... so, the following setup will NOT work: AppClass /path1/myfcgi.app Symbolic link from /document_root/fcgi-bin/myfcgi.app to /path1/myfcgi.app HTTP request made to /fcgi-bin/myfcgi.app --- NOT Why ? The fastcgi works a bit differently from CGI, so it need to maintain certain data structures about each configured application class (AppClass). In order to distinguish them, mod_fastcgi module uses their PATHNAME is a uniqe identifier (thus, not allowing definition of the multiple application classes with the name executable). This, however constitues a problem: when access to the fastcgi application is made, the mod_fastcgi module will try to find a data structure with the identifier /document_root/fcgi-bin/myfcgi.app, and not /path1/myfcgi.app and voila.. you get NOT_FOUND error return from the server. QuickFix: use AppClass /document_root/fcgi-bin/myfcgi.app in the config files and it should work (i think)....but There are 2 things to consider here.. first of all current implementation should work with the dynamically started applications (since they create data structures at first invokation and will contain symbolic pathname, which is good). However, it will not work if you have multiple symbolic links to the same executable (actually, it will create a copy of the data structure for each one, which is not what we want, since it is the same executable). Now, the solution (i am not going to implement it due to the lack of time, however, i am more than willing to apply patches :)) - introduce another field into FcgiServerInfo data structure, call it uniqId (char * or DString) - change the LookupFcgiServerInfo function to use uniqId field instead of execPath field it uses now. - change [External]AppClassCmd routines to do the following: stat execPath, then readlink execPath to obtain a full pathname to executable, then compute md5 hash of it (use GetHashedPath()) and stick it into uniqId. People familiar with the code will immediately realize that that is what we are doing to provide unique lockfile names, so common code can be reused. - change FcgiHandler to do the following: when request is recieved, do a stat/readlink/GetHashedPath() on the filename and then do your search. We do incur a a couple of system calls per each request, but the whole thing has to be optimized anyways, so if you can come up with some performance enhancements then great. - that's about all that needs to be modified. Stanley.