Hello!

On Thu, Apr 18, 2013 at 12:55:16AM -0400, davidjb wrote:

> I'm currently looking to extend the 'Auth Request'
> (http://mdounin.ru/hg/ngx_http_auth_request_module/) Nginx add-on module and
> have the module be able to conform (at least wherever possible) to the
> FastCGI "Authorizer" specification. The full specification is at
> http://www.fastcgi.com/drupal/node/22#S6.3 - the idea being the configured
> authorizer should be hit with a sub-request, and if a 200 is returned, then
> access allowed, with some manipulation of special headers. This is fine and
> I've successfully written extended the existing auth-request code.
>
> However, for any other response aside from 200, the Authorizer specification
> states that the server must send the response status, headers, and content
> back to the HTTP client. In my specific FastCGI authorizer, it sends various
> 301/302 redirects to do single sign on. This is where I've gotten stuck.
>
> So far, within the ngx_http_auth_request_handler function, I've managed to
> have this mostly working using this:
>
> ngx_http_request_t *sr;
> ...
> if (authorizer) {
> sr = ctx->subrequest;
> r->headers_out = sr->headers_out;
> return ctx->status;
> }
>
> which results in sending the subrequest's headers and status back to the
> client. I'm unsure if this is sensible in replacing headers in this fashion
> - eg performance or memory wise - so could some please comment on this? It
> does work though.

While this might work, I wouldn't recommend relying on it. This
way headers are processed within subrequest context, and then
again within main request context. This might potentially result
in headers being not in sync with filter module contexts,
resulting in invalid response. Safer aproach would be to copy
only specific headers.

(On the other hand, I don't think anything bad would happen with
standard filter modules, as most of them just ignore subrequests.)

> However, all that said, the subrequest's response body is the missing piece
> of the puzzle. I did figure out that the ``sr`` above defaults to
> ``sr->header_only = 1``, so it is ignoring the response body. However,
> turning this off results in the subrequest returning the body response to
> the client before main response headers can be sent -- exactly as per the
> discussion here: http://forum.nginx.org/read.php?2,222427,222543 .
> Curiously, only the sub-request response body is sent to the client, not the
> headers as well. If this behaviour for the subrequest could be changed to
> send its headers as well, then this would solve my problem.
>
> One way or another, I'd like to get the subrequest's response to the client
> as the whole response. Is this possible, and if so, how?

What you are trying to do should be possible with
NGX_HTTP_SUBREQUEST_IN_MEMORY - this way subrequest body will be
available in memory instead of being sent to a client. But it's
not currently supported for fastcgi.

--
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx