The HTTP headers are an untrusted path / channel, because end user clients have in general access to it.
There are mitigations in place, but we don’t know, if there is a way to circumvent them.
That’s why in several places Shibboleth documentation states [1, 2, 3], that you should stick to the secure channel “environment variables”, if possible. And using mod_wsgi (which has a daemon mode, too) it is possible.
For example 2, which was used in the other thread as a reference for the secure and stable state of the mitigation states:
In general, and this is noted below, you should always favor environment variables to request headers if the server platform supports that option. Environment variables cannot be influenced by the client and are much safer.
Please take the time and read the whole background section. Then the citation in the other thread sounds more like “It is better, than it was in the past. So that you have no reason anymore to disable the feature, if you need to use HTTP headers”.
As to the caveats and “industry standard” (is there any?):
Using Shibboleth is clearly a corner case here. AFAIK most (all?) other authentication systems don’t rely on webserver-specific modules and because of that don’t rely that much on having a secure communication channel between the webserver and the application server (secure means cannot be tampered with from the outside). So in other cases proxying at least doesn’t have security drawbacks.
Till now I didn’t run into any caveats of language specific server modules. All solutions have advantages and disadvantages. For me currently using mod_wsgi seems to have more advantages.
Best regards,
Enno