Re: Appclass/Virtual Host Configuration Problem

Stanley Gambarin (stanleyg@cs.bu.edu)
Wed, 24 Sep 1997 22:15:39 -0400 (EDT) 

Date: Wed, 24 Sep 1997 22:15:39 -0400 (EDT)
From: Stanley Gambarin <stanleyg@cs.bu.edu>
To: Jim Boutcher <jimb@novia.net>
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.