passenger_set_header silently ignores headers with underscores

[TLINDEN]

Issue report

Question 1: What is the problem?
When setting passenger_set_header to a header containing underscores, nothing is being visible in the application and there's no error or warning message in the logs.

This doesn't work, that is, the header is not being created and there's no hint anywhere about the when and why the header was being ignored:

 passenger_set_header       X_CLIENT_DN     $ssl_client_s_dn;

However, this does work:

 passenger_set_header       X-CLIENT-DN     $ssl_client_s_dn;

And besides, it not only works, but the header which then appears to the application is HTTP_X_CLIENT_DN (with underscores again).

• What is the expected behavior?

It shall just work or at least be reported to the error log. The documentation shall mention the undersore/dash translation behavior.

• What is the actual behavior?

Headers containing underscores are being ignored silently.

• How can we reproduce it?

I detailed the setup and test app on Stackoverflow.

Your answer:

Question 2: Passenger version and integration mode:

• nginx modules
• nginx/1.12.1
• Phusion_Passenger/5.1.8

Your answer:

Question 3: OS or Linux distro, platform (including version):

• FreeBSD 10.3, x86_64

Your answer:

Question 4: Passenger installation method:

Your answer:
[ ] RubyGems + Gemfile
[ ] RubyGems, no Gemfile
[ ] Phusion APT repo
[ ] Phusion YUM repo
[ ] OS X Homebrew
[ ] source tarball
[X] Other, please specify: ports

Question 5: Your app's programming language (including any version managers) and framework (including versions):

• ruby 2.3.5p376 (2017-09-14 revision 59905) [amd64-freebsd10]

best regards,
TOm

[OnixGH]

Hi Tom, this behavior is intentional, to avoid a security vulnerability.

The option works similar to the proxy_set_header directive of the Nginx http proxy module (as mentioned by our docs), which also filters underscores by default.

I agree it could be made more explicit there, so I moved the issue there: phusion/passenger_library#68

Btw. we had considered logging but it's not great for per-request errors (log flood).

[TLINDEN]

Btw. we had considered logging but it's not great for per-request errors (log flood).

Well, but you could just report a fatal error and die, since such variables are not supported anyway.