Re: questions after reading fcgi-spec.html
Bill Snapper (snapper@gigapacket.com)
Fri, 15 Aug 1997 15:55:11 -0400
Message-Id: <3.0.3.32.19970815155511.0097cd00@shultz.gigapacket.com>
Date: Fri, 15 Aug 1997 15:55:11 -0400
To: Sonya Rikhtverchik <rikhtver@OpenMarket.com>
From: Bill Snapper <snapper@gigapacket.com>
Subject: Re: questions after reading fcgi-spec.html
In-Reply-To: <199708151411.KAA07521@u4-138.openmarket.com>
1) Process Affinity
Process affinity doesn't really have anything to do with FastCGI. It's
something that a Web Server may choose to implement so that you could
direct http requests to the same FastCGI process each time (assuming
that a URL maps to multiple FastCGI processes doing the same job).
Consider the following example:
- A web server has a URL mapped to a set of FastCGI processes which are
all listening for connections on a different port (either unique domain
socket name or unique TCP port).
- The Web server will choose which process to hand an incoming request to
by hashing a unique field in the http request. Let's say that the URL
being accessed is protected using basic auth which caused the
"authorization" to be sent from the browser.
a) request arrives for /fcgi/DoStuff.fcgi
b) Web server notices that the "authorization" header is not present
and the region "/fcgi/" requires basic auth and it redirects back to
the browser for username/password.
c) browser resubmits the request and this time the "authorization" header
is present.
d) the web server has a rule that says, any time someone accesses the URL
"/fcgi/*", perform an "AffinityMap" directive and use the header to
compute which process to connect to.
The "AffinityMap" directive performs a hash of the "authorization"
header and comes out with a number which is used to figure out which
process to choose. Since the "authorization" is the same for each
subsequent request for this session, the same number is computed and
therefore the same process is chosen.
e) The web server runs the request.
Notice that there was no authorizer used in this example and that FastCGI
really didn't do anything with affinity in particular. It was the Web
Server's plugin which performed the FastCGI protocol that implemented a
policy allowing process affinity.
2) Someone wrote:
>How can an authorizer decide to authorize or unauthorize if it does not get
>FCGI_STDIN or at least FCGI_DATA. (I assume FCGI_DATA is equivalent to the
CGI
>GET parameters, is it.)
>
You have to think what a FastCGI authorizer is first. It's a mechanism
which allows you to perform authorization from a custom application
to either grant or deny access to a particular area of content on a
web site. This content could contain static html files, CGI scripts,
custom web server plugins. The FastCGI authorizer will run in the
context of the same request that the is requesting access to a particular
URL.
Consider the case where the file "/foo/users/stuff.html" is being
protected
by an authorizer. The sequence of events that take place to access this
file is roughly as follows (note that some stages were left out in order
to simplify the explanation).
- The Web Server has the following directives in it's conf file:
AppClass MyAuthApp /bin/fcgiAuth
AuthorizeRegion /foo/users/*" MyAuthApp
This tells the server that any URLs with a pattern match of
"/foo/users/" should run the authorizer described by MyAuthApp.
a) Web Server gets and decodes the request for "/foo/users/stuff.html"
This involved reading the HTTP header and only the header. There
is no standard input (i.e. POST data) read as we don't know if there
is any or if it's worth reading.
b) Web Server goes to it's access check phase to see if there's any
access control policies applied for this access like basic auth,
requires SSL, etc. It detects that there is a pattern registered
and it belongs to a FastCGI Authorizer.
c) The Web Server will run the request through the FastCGI Authorizer
application to perform the access control. The Authorizer has access
to the standard set of CGI environment variables minus the following
four: CONTENT_LENGTH, PATH_INFO, PATH_TRANSLATED, SCRIPT_NAME. This
is per the FastCGI spec. It has to use the information it has access
to to perform the access control. It might be that it uses info in
the URL, it might use the HTTP authorization header or lack of one
to request one, etc.
d) The FastCGI authorizer's results get seen by the Web Server's HTTP
access control code and decides whether to let the request run or
not. If the FastCGI authorizer returned "200 OK", the HTTP request
resumes and performs the requested action. If not, the error returned
by the authorizer gets returned to the Web Client and the HTTP
request terminates at this point (ie. access was not authorized and
therefore the request was denied).
Now consider the authorizer was protecting "fcgi/users/DoStuff.cgi" and
"DoStuff.cgi" read standard input data. If the authorizer read this and
consumed it, how would the CGI app get it? You have to realize that
the Authorizer is really only performing access control and is not doing
any web type of operation. If you think of it as analogous to a Web
Server performing "Basic Authentication" using username/password, I think
the fact that it doesn't read STDIN will make sense.
I hope this information helps to illustrate:
o what process affinity is.
o how process affinity is really not part of the FastCGI spec as far
as the protocol is concerned
o how an authorizer runs.
- Bill -
At 10:11 AM 8/15/97 -0400, Sonya Rikhtverchik wrote:
>
>Date: Fri, 15 Aug 1997 10:22:23 +0000 (GMT)
>From: "=?ISO-8859-1?Q?P=E9ter_Verh=E1s?= DTN: 798-5435"
> <VERHAS@A1.BPSOF.BPS.mts.dec.com>
>Subject: questions after reading fcgi-spec.html
>To: rikhtver <rikhtver@OpenMarket.com>
>Message-Id: <E263ZWZCHZEFG*/R=BPS/R=BPSOF/R=A1/U=VERHAS/@MHS>
>MIME-version: 1.0
>Content-type: TEXT/PLAIN; CHARSET=US-ASCII
>Content-transfer-encoding: 7BIT
>Posting-date: Fri, 15 Aug 1997 10:35:00 +0000 (GMT)
>Importance: normal
>Priority: normal
>UA-content-id: E263ZWZCHZEFG
>X400-MTS-identifier: [;62530151807991/632139@BPSOF]
>A1-type: MAIL
>Hop-count: 3
>
>I hope you do not mind my writing you directly. I feel that my questions are
>newbie and it could be worthless disturbing others. I am sorry disturbing
you.
>
>Fci-spec.html does not mention process affinity. Where is it detailed?
>
>FastCGI does not deal with how the processes are started, or restarted. This
>is
>a Web server implementation issue. If this is the case how can the
authorizer
>tell the Web server:
>
> Hey, this is a user just wanting to log in, starting a session,
> for which I need a new process. Please start one!
>
> or: Start one on machine XYZ_SERVER! (load balancing)
>
>or how can it say:
>
> I know this hit comes from user XYZ. Dear Web server, please
> issue the hit to the process XYZ_PID on server XYZ_SERVER as this
> is the process for this users.
>
>How can an authorizer decide to authorize or unauthorize if it does not get
>FCGI_STDIN or at least FCGI_DATA. (I assume FCGI_DATA is equivalent to the
CGI
>GET parameters, is it.)
>
>Regards,
>Peter
>
>
>------- End of Forwarded Message
>
>
>
>
>