Intended behavior for Host header in Proxy scenario

[Jack Henschel]

Hi Maxim,

thanks for the quick confirmation!

> The Host header is set to what you wrote in the "proxy_pass" by  default.  That is, it will be "backend" with the above configuration.

Wouldn't it make more sense to use the hostname from the particular upstream server?
I see two scenarios where this is required:

1. TLS secured upstream servers. TLS verification requires the correct Host header to be set (i.e. "a.example.com" instead of "backend"). Though I know there is the possibility of doing this (additionally) with TLS client certificates.

2. Upstream vhosts. Consider the scenario where multiple domains point to the same IP address, where the requests are split apart based on the Host header (I.e. virtual hosts)

What do you think?

Regards
Jack


On 22 November 2018 22:13:38 CET, Maxim Dounin <mdounin at mdounin.ru> wrote:
>Hello!
>
>On Thu, Nov 22, 2018 at 09:11:59PM +0100, Jack Henschel wrote:
>
>> Hello everyone,
>> 
>> during my last debugging session with Nginx I was wondering how and
>when
>> exactly Nginx passes upstream's hostname when proxying a request.
>> 
>> In particular, I have the following example:
>> > upstream backend {
>> >   server a.example.com:443;
>> >   server b.example.com:443;
>> > }
>> 
>> > server {
>> >   proxy_pass https://backend/path;
>> >   proxy_set_header Host $proxy_host; # default according to docs
>> > }
>> 
>> I observed that Nginx does not always pass the appropriate Host
>header
>> to the upstream server (i.e. "a.example.com" for "server
>> a.example.com:443" and "b.example.com" for "server
>b.example.com:443").
>> 
>> Is this observation correct or am I missing something?
>
>The Host header is set to what you wrote in the "proxy_pass" by 
>default.  That is, it will be "backend" with the above 
>configuration.
>
>-- 
>Maxim Dounin
>http://mdounin.ru/
>_______________________________________________
>nginx mailing list
>nginx at nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20181123/1c7e228a/attachment.html>