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

As for the code I've written, the input headers are being modified after the subrequest has been completed, and this appears to succeed. So no seg faults so far.