SCRIPT_NAME header is dropped/rejected by header map validation

[jhominal]

From the Gunicorn documentation, and the corresponding code, it is possible to use a SCRIPT_NAME HTTP header to set the SCRIPT_NAME key in the WSGI environment for the corresponding request.

However, as SCRIPT_NAME contains an underscore, it is dropped by the new code in parse_headers by default.

I think that SCRIPT_NAME should be special-cased by the header validation logic, as it cannot be confused (it never gets added as HTTP_SCRIPT_NAME in the WSGI environment, so it would never conflict with a Script-Name header anyway).

[pajod]

Sorry, my attempt at closing the dash/underscore problem modified was excessive for that use case. Note that when gunicorn pulls something from a header and puts it into environ the problem is slightly different. The issue then is not that the application cannot tell which HTTP_* header it (the dash or the underscore one) it is reading from. The issue is that the application cannot tell what is received from the authorized proxy and what is external input.

You can neutralize the code discarding the underscore headers using the --header-map dangerous escape hatch provided in the same patch. Do so only when you know your application (or applicable frameworks & libraries) will robustly deal with maliciously crafted invalid input in such headers (if they can receive such).

A more nuanced solution is suggested in #3192 but still needs better documentation and review.

[burnettk]

here's a minimalish repro, in case it's helpful to anyone: https://github.com/sartography/repro-gunicorn-22-0-0-regression