Doing an "upstream" request without sending result back to client

[Vincent Gross]

On Mon, Dec 02, 2013 at 05:48:40PM +0400, Maxim Dounin wrote:
> Hello!
> 
> On Mon, Dec 02, 2013 at 09:22:50PM +1100, Vincent Gross wrote:
> 
> > Hi folks,
> > 
> > I want to implemement a webid authn module in nginx. This is the big picture:
> > 
> > 1. Client do an https request and sends a client cert
> > 2. Certs contains a subjectAltName URI, e.g. https://mysite.info/id/
> > 3. Server fetches https://mysite.info/id/ content
> > 4. If content do contains public key info matching client cert, authn
> >    successful.
> > 
> > From what I see in src/http/ngx_http_upstream.c in functions
> > ngx_http_upstream_process_header(ngx_http_request_t *, ngx_http_upstream_t *)
> > & ngx_http_upstream_send_response(ngx_http_request_t *, ngx_http_upstream_t *),
> > it is not possible to do the request [3] without sending back at least a
> > response header back to the client.
> > 
> > Did I miss something or am I really setting myself for reimplementing the
> > mechanisms of ngx_http_upstream.c? Any advices/guidelines for the latter (other
> > then taking example on original upstream?)
> 
> You may try looking into subrequests, in particular - 
> NGX_HTTP_SUBREQUEST_IN_MEMORY functionality.

Thank you for the reply Maxim, I gave it a quick shot based on your auth
request module.

As I understand it, subrequests are always done in the current server space, so
if want to GET on a foreign server, I would need an other location with some
substitutions to appropriately fill the proxy_pass value. Am I right ?

Also this means I need to add a location whose sole purpose is to translate
from inner reqs to outer reqs, I don't feel good abusing the config file in
such a way, given that the whole point of webid is to have decentralized authn.

Cheers,

--
Vincent
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20131203/19cc4ecd/attachment.bin>