Search code examples
phpapacheproxyhttp-proxymod-proxy

Content-Encoding header disappearing through forward proxy


I'm having a strange issue with Apache 2.4.25 on Debian 9. I'm curling a page in PHP proxying through another Apache server which is set up as a forward proxy. The idea is to pass everything through unmodified but the outbound traffic is issued from the proxy.

I've noticed that when I do this, if I fetch a webpage with a Content-Encoding header, the header doesn't seem to come through. When I load the page in my browser directly, I receive the header. When I trying curling without a proxy, I also get the header.

How can I force the Apache proxy to not delete this header, but pass all the headers it receives on verbatim, unmodified? There doesn't seem to be anything in the documentation about this, unfortunately, and it's imperative that I get the original Content-Encoding header.


Solution

  • The problem turned out not to be Apache, thankfully, but actually my curl statement in PHP.

    Adding the following option fixes it:

    curl_setopt($ch, CURLOPT_ENCODING , "");
    

    Got my inspiration to try this from a slightly related question.

    • CURLOPT_ENCODING instructs curl to request HTTP compression, if supported
    • The "" string is empty, so as not to force any particular compression method. If the server supports any form of compression, we'll get that page back with that compression method.

    Now, if I run a test again, I see the following additional header:

    content-encoding      gzip
    

    Not sure why it seemed to work without a proxy, but always best to specify this option explicitly. Unlike most browsers, PHP cURL won't request compression unless you tell it to, but it's an easy fix.