Nonstandard Response Headers
manlio_perillo at libero.it
Mon Jan 21 12:21:00 MSK 2008
Brendan Schwartz ha scritto:
>> But try with:
>> set $authorization upstream_http_authorization;
>> set $some_other upstream_http_some_other_header;
>> in the / location
>> proxy_set_header Authorization $authorization;
>> proxy_set_header Some-Other-Header $some_other;
>> in the remote-proxy location
>> However I'm rather sure that this will not work :).
>> Manlio Perillo
> Unfortunately this doesn't seem to work. "set $authorization
> upstream_http_authorization;" sets the $authorization variable to the
> string "upstream_http_authorization".
Yes, you are right, sorry.
> If I change the line to "set
> $authorization $upstream_http_authorization;", it doesn't work either.
> I think that's because in Location / the Authorization header isn't
> set yet -- it's set by the local backend.
Try to use $upstream_http_authorization directly in the remote-proxy
If this does not work, then I have no idea on how to solve your problem.
> I'm trying to use nginx as a proxy for a remote server. But in order
> to access the content on the remote server, I need to pass an
> Authorization header to it. The local backend is able to produce valid
> authorization tokens.
> So here's what I want to happen: the local backend produces an
> Authorization header which is then passed to the remote server
> backend. The remote server accepts the authorized request and returns
> the protect content to nginx which passes it on to the end user.
> Does this make sense?
Why don't just ask the user to supply the Authorization header?
Moreover, since the remote-proxy is "internal", I don't see any need to
supply authorization info.
The authorization *must* be done in the local backend, and only if the
client is allowed to access the protected content, you set the
This content is only accessible by nginx, and not by external clients.
More information about the nginx