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
>
>
>
>
>