I've got my .htaccess file set to the following:

 Header set MyHeader "I'm Set!"

If I go to that directory (http://example.com/test/), which has no default index file, and view the network activity (in this case with Chrome), I can see that the header is being sent. If I go to a php file (http://example.com/test/test.php), the header isn't sent.

I've created an index.html (with simply <pre>Hi as the content) and it gets sent. I change the file name to .php, no header. If I change the orignal test.php to test.html, it outputs the garbage-looking code, and the header is sent. If I change test.php to test.png, I get a broken image icon, and the header is sent.

So, without testing beyond the above in terms of mime-type and file extensions, it appears only .php files (legit or otherwise) are either set to not have .htaccess rules apply or specifically the mod_headers directives. But I don't know how to test for this and because it's a shared server, I don't have httpd.conf access to poke around.

Any ideas as to why apache would skip sending headers for php files?

I've also tried:

 <FilesMatch "\.(php)$">
     Header set MyHeader "I'm Set!"
  • Updating from PHP/CGI to PHP/FastCGI seems to have fixed it. I'm still very eager to get feedback if anyone knows what the root cause was.
    – Anthony
    Apr 25, 2012 at 15:05
  • 1
    Anthony, did you use mod_fastcgi? I experience exactly the same behavior and it seems to me that mod_fastcgi breaks mod_headers functionality. I posted this bug report yesterday: bugs.launchpad.net/ubuntu/+source/libapache-mod-fastcgi/+bug/…
    – Onkeltem
    Sep 12, 2014 at 10:28
  • same here :/ any news or workaround that? I can't imagine this is not a problem in more cases out there... May 15, 2017 at 11:44

1 Answer 1


This is expected behavior when running CGI scripts. From the latest (2.4) version of the mod_headers docs:

The default value of onsuccess may need to be changed to always under the circumstances similar to those listed below. Note also that repeating this directive with both conditions makes sense in some scenarios because always is not a superset of onsuccess with respect to existing headers:

You're modifying or removing a header generated by a CGI script, in which case the CGI scripts are in the table corresponding to always and not in the default table.

The original issue (with, perhaps, a better explanation) is in Bug 49308.

  • If I'm reading that correctly, using Header always set MyHeader "I'm Set!" should have solved the issue. I think I found an answer where someone suggested that and it didn't work for the OP in that case either. But I'm also pretty sure they said to try Header set always, which may have been why that suggestion failed.
    – Anthony
    Apr 25, 2012 at 17:15
  • Nope, I take it back. I ctrl-z'd to that attempt and it was Header always set. Am I just misreading the quote?
    – Anthony
    Apr 25, 2012 at 17:17
  • In your original question you don't have that specified; are you sure its set? It should be something like Header always set MyHeader "I'm Set!", according to your example.
    – Andrew M.
    Apr 25, 2012 at 18:32
  • Well, I did try it, though without the endorsement of Apache, so I may have given up on one try. And now that it's working, I'm stuck with just assuming it was the switch from CGI to FastCGI, but I'm suspicious all around.
    – Anthony
    Apr 25, 2012 at 22:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.