Project

General

Profile

Feature #2770

Override proxified Host header

Added by altblue 11 months ago. Updated 10 months ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
mod_proxy
Target version:
Start date:
2016-11-22
Due date:
% Done:

100%

Estimated time:
Missing in 1.5.x:

Description

Name based virtual host handlers used as backends through lighty's mod_proxy get a better change to properly handle proxified requests by overriding Host header.

Following an idea posted in Docs_ModProxy, the optional name (that shows up in the generated statistics of mod_status) will be used as value for Host header.

Additionally, it will turn HTTP/1.0 into HTTP/1.1.

lighttpd-1.4.43-mod_proxy-host.patch (1.44 KB) lighttpd-1.4.43-mod_proxy-host.patch altblue, 2016-11-22 19:16
lighttpd-1.4.43-mod_proxy-host.patch (3.25 KB) lighttpd-1.4.43-mod_proxy-host.patch proxy.use-backend-name-as-http-host altblue, 2016-11-26 19:03
lighttpd-1.4.43-mod_proxy-host.patch (3.63 KB) lighttpd-1.4.43-mod_proxy-host.patch proxy.replace-http-host gstrauss, 2016-12-02 04:57

Associated revisions

Revision 879ce0b5 (diff)
Added by gstrauss 10 months ago

[mod_proxy] replace HTTP Host sent to backend (fixes #2770)

replace HTTP Host sent to backend if configured with
proxy.replace-http-host = "enable"
and lighttpd.conf proxy.server definition provides replacement Host

(thx altblue)

x-ref:
"Override proxified Host header"
https://redmine.lighttpd.net/issues/2770

History

#1 Updated by gstrauss 11 months ago

  • Target version deleted (1.4.44)

Interesting ideas, but there are some issues.

First, you can not change the request to the backend from HTTP/1.0 to HTTP/1.1 unless mod_proxy is updated to support HTTP/1.1, including being able to accept Transfer-Encoding: chunked in responses, and to de-chunk if the client to lighttpd is HTTP/1.0. Additionally, using HTTP/1.1 is not required for what you are trying to do, which is to send a custom Host header. You can send Host header with HTTP/1.0.

Second, your patch might break existing usage, since current users are not expecting that value to suddenly override the Host header provided by the client. For this patch to be considered, the behavior introduced by your patch would need to be made optional behavior, and disabled by default.

#2 Updated by altblue 11 months ago

gstrauss wrote:

can not change the request to the backend from HTTP/1.0 to HTTP/1.1

Indeed, that is a stupid overreach, please ignore it, it should not be useful to general audience. IIRC it was driven by some picky backends that did not want to process lighty's proxified requests unless they were marked HTTP/1.1. While sloooowly rebasing a series of ancient patches to 1.4.43, I eagerly submitted this kludge too. My apologies. :-(

patch might break existing usage, since current users are not expecting that value to suddenly override the Host header provided by the client.
For this patch to be considered, the behavior introduced by your patch would need to be made optional behavior, and disabled by default.

I doubt there are users counting on Host to exist while talking HTTP/1.0 (i.e. instead of using the provided X-Host - but that's kinda new too, I don't remember it being there), but anyway, I fully agree it's safer to hide it behind a switch. Thanks. :-)

#3 Updated by altblue 11 months ago

[mod_proxy] proxy.use-backend-name-as-http-host

Set proxy.use-backend-name-as-http-host = 1 to enable using the optional
<name> that shows up in the generated statistics of mod_status

#4 Updated by gstrauss 11 months ago

Thanks for the updated patch.

Would you be averse to me renaming the directive to something shorter, such as "proxy.replace-http-host"?
Should the HTTP Host be forced, even when one is not provided in the original request? (I think it should.)

#5 Updated by altblue 11 months ago

gstrauss wrote:

Would you be averse to me renaming the directive to something shorter, such as "proxy.replace-http-host"?

Name it whatever you like, configuration parameter brevity was not my goal, I tried to use something that is as self-explanatory as possible.

Should the HTTP Host be forced, even when one is not provided in the original request? (I think it should.)

The Host header provided in the original request is inconsequential for this feature: backends shall receive the name (as Host header) if it's configured as such. Hence, I don't reckon enforcing to be necessary.

#6 Updated by gstrauss 11 months ago

updated patch to follow pattern in recent bugfix 5bf5e1ad and renamed directive to proxy.replace-http-host. Patch has not been tested. Please see if this is acceptable to you.

#7 Updated by gstrauss 11 months ago

  • Status changed from Patch Pending to Need Feedback

#8 Updated by gstrauss 10 months ago

  • Status changed from Need Feedback to Fixed
  • % Done changed from 0 to 100

Also available in: Atom