Maybe a clear exception in case of excessive number of redirects that tells the developer that it should either implement solution one or solution two.

the thing is, I don't think we can know about this excessive number of redirects, due to the stateless nature of HTTP (the browser can detect such case, as it is the one following redirection).

Among your possible solutions, the first proposal is not a solution. It is a hack trying to partial trust a proxy header without making it a trusted proxy (and if your app is accessible without going through the proxy, it might open a security hole in your app).
When deploying to heroku, the right solution is the second one: as heroku runs a proxy in front of your app (their load balancing router), you need to configure the proxy as trusted. and Heroku even documents it: https://devcenter.heroku.com/articles/getting-started-with-symfony#trusting-the-load-balancer

@stof , you are right: the first solution is a hack and the preferred way of solving the problem is adding the trusted proxies.

Anyway, the problem is that, before understanding what is really going under the hood and from where it comes the redirection, you have to spend a lot of time.

I don't know if it is possible to intercept the loop: I cannot come up with a solution but maybe someone of you with more experience can :)

Anyway, if no solution is possible, the best approach would be to add to the docs a note about this problem that is known and intended, maybe also a link to the Heroku documentation or to the trusted_proxies... I don't know.

The only thing I know is that to discover the source of the loop I spent really a lot of time as this is something you set once and then forget.

Just as a side note, thank you for the link to the Heroku documentation: when I started with Heroku it didn't exist and I didn't find it searching for the issue on Google.

What about something like this in ChannelListener::handle()? (untested)

     public function handle(GetResponseEvent $event)
     {
         $request = $event->getRequest();
 
         list(, $channel) = $this->map->getPatterns($request);
 
         if ('https' === $channel && !$request->isSecure()) {
             if (null !== $this->logger) {
                 $this->logger->info('Redirecting to HTTPS.');
+                if ('https' === $request->headers->get('X-Forwarded-Proto')) {
+                    $this->logger->debug('Possible redirect loop - did you set the trusted_proxies correctly?');
+                }
             }

             $response = $this->authenticationEntryPoint->start($request);

             $event->setResponse($response);

             return;
         }

That would at least give you a hint in the logs.

Of course this is also one of those problems that once you (finally) figure it out the first time, it's easy to spot and fix again in the future.

Ninja-edit: revised the logger to use debug() and improved the log message.

@colinodell , yes, but this is also something that yu set once and then forget about it.

If you only manage one application (like me), you forget about it.

I spotted the problem about 1 year ago the first time and now, upgrading to SF4 I had to spot it again as I completely forgot I used the hack...

More, as I didn't know anything about this problem, I used the hack, so my app was potentially vulnerable without I knowing nothing about.

For me a good approach would be to, other than logging the message like you shown, also to add a not in the documentation about the potential loop where is explained how to force https.

@Aerendir I have submitted a PR for both the logging message and documentation update