什么时候需要ProxyPreserveHost ?

背景

在apache httpd 中设置Reverse Proxy的时候通常我们有如下配置

# https://myfrontend/images => https://mybackend/images
ProxyPass /images https://mybackend/images
ProxyPassReverse /images https://mybackend/images

ProxyPass不多说了，ProxyPassReverse是把response中的Location, Content-Location, URI等header由mybackend替换成myfrontend。
今天配置服务器的时候，发现如果以上配置情况下，如果还有ProxyPreserveHost on配置，则我们的https://myfrontend/images的response变成了403。这是为什么呢？

ProxyPreserveHost 的作用

ProxyPreserveHost 的作用如文档上写的，很简单，当我们设置ProxyPass /images https://mybackend/images的时候，通过myfrontend服务器发往mybackend的request的Host Header应该是Host: mybackend。
而如果ProxyPreserveHost on,则我们的request的header则回变成Host: myfrontend。

文档上说，我们大多数情况下不需要这个配置。除非在mybackend上配置了大量的vhost，我们需要通过识别原来request的Host header来判断request交给哪个vhost处理。

这种说法略抽象，让我们在稍微深入考虑一下。

当我们的mybackend的服务器上，配置有myfrontend的vhost的时候，使用ProxyPreserveHost on就可以把我们的request交给myfrontend的vhost来处理。

这个时候，这个配置在mybackend上的vhost myfrontend是无法外部的DNS来resolve的。外部的DNS把myfrontend已经resolve到了我们的Reverse Proxy服务器。

所以当ProxyPreserveHost on 的时候就会有如下流程。

https://myfrontend/images(user request) => myfrontend(Reverse proxy to mybackend server with Host: myfrontend ) => mybackend(match with vhost setting as myfrontend)

因为在大多数情况下，我们通常不会在mybackend的服务器上配置和Reverse Proxy一模一样的vhost，所以就如文档中所说，我们大多数情况下不需要此配置。

后话

在web的世界里，当我们的目标服务器上配置有DNS无法resolve的vhost的时候，通常我们可以用ip+port，设置Host header为该无法resolve的vhost的方法来访问。
这个容易忽视的web的实质面貌，在本次讨论的问题中体现的淋漓尽致。