Custom HTTP header fields stripped

By | December 7, 2017

My company sells a LAMP-based (where P = Perl, not PHP) application deployed as an appliance. A customer is attempting to integrate their SiteMinder SSO with our application, such that our appliance sits behind a proxy running a SiteMinder Apache plugin that acts as a gatekeeper. For our application to authenticate a user via SSO, we expect to see HTTP requests that include an SSO cookie (SMSESSION in this case) and a custom HTTP header variable containing the username.

However, when our Apache server receives HTTP requests from the SSO proxy, all custom HTTP appear to have been stripped, although the cookie is present. I have instrumented the Perl code to write the headers to a log file with the following code:

my $q = new CGI;
my %headers = map { $_ => $q->http($_) } $q->http();
my $headerDump = "Got the following headers:\n";
for my $header ( keys %headers ) {
    $headerDump = $headerDump . "$header: $headers{$header}\n";
kLogApacheError("info", $headerDump);

…and this is the output I get (slightly edited for confidentiality):

[Wed Mar 16 23:47:31 UTC 2011] [info] Got the following headers:
        HTTP_COOKIE: s_vi=[CS]v1|26AE2FFD851D091F-4000012E400035C5[CE]; s_nr=1297899843493; [snip]
        HTTP_ACCEPT_LANGUAGE: en-US,en;q=0.8
        HTTP_ACCEPT_ENCODING: gzip,deflate,sdch
        HTTP_CONNECTION: keep-alive
        HTTP_ACCEPT: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
        HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.3
        HTTP_USER_AGENT: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.107 Safari/534.13
        HTTP_HOST: [redacted].com

IOW, the customer HTTP headers I’m expecting are missing. When we redirect traffic from the proxy to a different Apache server (i.e. not our appliance) all the 20+ custom headers show up as expected. This strongly suggests that it’s our Apache server that is stripping the headers.

We have never run into a problem like this with other deployments, even with this particular SSO solution. I realize this is similar to another question on this site ( Server removes custom HTTP header fields ) but the suggestions there (such as a problem caused by running mod_security) don’t apply.

Is there any other reason why our server might be stripping out the HTTP headers? Or is there possibly something else going on?

Thanks for any help!



Have you sniffed the raw HTTP traffic between the proxy and your Apache instance? If the necessary headers are missing herein, the problem is on the proxy side.


I finally figured this out, and it was pretty obscure…

Using HttpFox, it really looked like traffic was being redirected to the appliance rather than being forwarded. In the case of redirects, cookies were persisting but HTTP request headers were not. However, the SSO Proxy rules were all “forwards” so we were completely stumped as to why redirects were showing up.

We knew that our application’s logic redirects to /signin/ if the user isn’t already authenticated but we expected this would still be routed through the proxy. However, what we didn’t realize is that there was a SiteMinder SSO option, enableredirectrewrite that by default would handle “any redirects initiated by destination servers [by passing them] back to the requesting user”. Once we set this flag to “yes”, and the redirectrewritablehostnames to “all”, everything worked like magic.

(For reference, see a version of the SiteMinder manual here:


I recently had a problem where I could not get any custom HTTP Headers passed to my PHP Script.
It seems that Apache 2 running PHP 7 with FCGID would not allowing and removing or tripping all custom HTTP Headers.

Here is my fix:

Leave a Reply

Your email address will not be published. Required fields are marked *