Hello! On Tue, Apr 23, 2013 at 07:23:26PM -0400, davidjb wrote:
> Maxim Dounin Wrote: > ------------------------------------------------------- > > For me it doesn't looks like what you do actually matches FastCGI > > Authorizer specification. Even if we ignore the fact that body > > isn't handled properly, and authorizer mode isn't advertized to > > FastCGI. > > > > Most of the code in the patch seems to be dedicated to special > > processing of Variable-* headers. But they don't seem to do what > > they are expected to do as per FastCGI spec - with your code the > > "Variable-AUTH_METHOD" header returned by an authorizer will > > result in "AUTH_METHOD" header being passed to the application, > > i.e. it will be available in HTTP_AUTH_METHOD variable in > > subsequent FastCGI requests - instead of AUTH_METHOD variable as > > per FastCGI spec. > > It's still very much a work in progress (fwiw, I started using Nginx last > week). On another read of the FastCGI specification, I do agree that your > interpretation is right - I was interpreting part of the specification > without understanding the rest of the definitions. So, in that regard it > could certainly be improved. > > However, if strictly adhering to the FastCGI spec, this would thus force the > backend application to be FastCGI as well -- and this is why my code does > what it does. The authorisation technology (Shibboleth) I'm working with > needs to inject user-related variables into the request going to a backend > application, and for ease of use/performance, I don't want to have to > re-route via a FastCGI application. > > So perhaps on balance, this functionality may well be better suited to its > own add-on module. Note that if you just need to pass some variables you know about - it can be easily done with auth_request_set and fastcgi_param directives. > > Please also note that it's bad idea to try to modify input headers - > > this is not something expected to be done by modules, and will > > result in a segmentation fault if you'll try to do it in a > > subrequest. > > Okay, but what of a module like "Headers more" -- which allows you to > manipulate any headers, incoming or outgoing. Should something like this > not exist for Nginx or is it just considered 'bad practice'? Either way, > I'd be curious for both the code I've written, and also as I'm relying on > the "Headers more" module to drop certain request headers. This is considered bad and unsupported by nginx core. You may take a look at headers more module for a number of quirks it uses for this to work. Recommended aproach is to use variables and appropriate backend protocol module directives (proxy_set_header, fastcgi_param, ...) to pass them to a backend. An example of similar functionality in nginx core: proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header http://nginx.org/en/docs/http/ngx_http_proxy_module.html#variables -- Maxim Dounin http://nginx.org/en/donation.html _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
