Accessing a Symfony app using Chrome's Data Saver causes BadRequestHttpException

Question

Accessing my Symfony website using Chrome’s Data Saver on Android generates an error 500.

Here is the log

[2017-04-06 18:56:23] request.ERROR: Uncaught PHP Exception
Symfony\Component\HttpKernel\Exception\BadRequestHttpException:
"The request headers contain conflicting information regarding the origin of this request." at /home/myapp/app/bootstrap.php.cache line 3184
{"exception":"[object] (Symfony\\Component\\HttpKernel\\Exception\\BadRequestHttpException(code: 0): The request headers contain conflicting information regarding the origin of this request. at /home/myapp/app/bootstrap.php.cache:3184, Symfony\\Component\\HttpFoundation\\Exception\\ConflictingHeadersException(code: 0): The request has both a trusted Forwarded header and a trusted Client IP header, conflicting with each other with regards to the originating IP addresses of the request. This is the result of a misconfiguration. You should either configure your proxy only to send one of these headers, or configure Symfony to distrust one of them. at /home/myapp/app/bootstrap.php.cache:788)"} []

From what I understand Chrome’s Data Saver acts as reverse proxy in front of my application compressing code and images.

I read this doc about how to use a reverse proxy in front of a Symfony app.

The problem is I don't find any doc about the IP Chrome’s Data Saver proxy is using.

Thanks for help!

Answer 1

The crucial information lies here:

The request has both a trusted Forwarded header and a trusted Client IP header

I would recommend fixing the issue or - if you don't have permissions - disable the conflicting header as described in the documentation:

• https://symfony.com/doc/current/components/http_foundation/trusting_proxies.html#not-trusting-certain-headers

You probably want to do this in your app.php or app_dev.php in your web/ directory. Right after the $request is created.

Answer 2

That this error also affects Drupal 8.3 (and probably 8.0/1/2 too). And you can't really trust that FORWARDED header since it can be faked like any other, and you can't (AFAIK) list the proxy addresses from which to accept it. So whenever a user enables the Chrome Data Saver, you essentially lose the ability to get their IP because you can't rely on the FORWARDED header.

The default behavior of trusting X_FORWARDED_FOR works if you accompany it with the list of trusted reverse proxies (i.e. the ones you have control over).

Which can be a problem where law forces you to keep track of user IPs for any user-generated content (as in France).