Subrequests: returning response to client

Maxim Dounin mdounin at mdounin.ru
Thu Apr 18 08:55:13 UTC 2013


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



More information about the nginx mailing list