Added support for x-forwarded-proto header to request object

[SteveReiter]

No description provided.

[SteveReiter]

Relates to #123

[Xerkus]

All in all, i think proper place to add support for the header is not here but at https://github.com/zendframework/zend-http/blob/release-2.7.0/src/PhpEnvironment/Request.php#L254

[Xerkus]

There is no reason to introduce this class.
$uri->setScheme('https'); provides exactly the same behavior

[Xerkus]

This will end up overriding scheme each time Uri is fetched from Request. Getters must not have side effects

[Xerkus]

This breaks Uri contract by ignoring scheme changes
Besides, internal logic will be broken in unpredictable ways where scheme property is used directly

[Xerkus]

You don't need all the headers. Use has() and get()

[weierophinney]

There are multiple ways of doing this.

First, as suggested in #123, you could write a controller plugin for this. In that case, you can look not only at the scheme of the URI composed by the request, but also at the X-Forwarded-Proto header to determine what to return.

Second, you could create a listener that triggers at either low priority in the bootstrap event or high priority in the route event that resets the URI scheme based on the presence and value of the X-Forwarded-Proto header.

Third, we could directly support this via the Zend\Http\PhpEnvironment\Request object, and, if that header is detected during initialization, set the URI scheme based on it.

All three of these are preferable to the approach you are presenting here. As @Xerkus notes, the changes you are introducing mean that users would be surprised if the scheme did not update. Additionally, it still requires the user to update their system to inject the alternate URI instance — and if you have to do that, one of the above approaches will be just as successful.

I will consider an approach in this package that implements the third option I outline above, or an approach in the zend-mvc pacakge that implements the second option above.

[weierophinney]

Closing due to inactivity. Re-submit if you are able to implement one of the options outlined in my last comment above.

[intellent]

Just one addition to this. We use a nginx reverse proxy to terminate SSL and the X-Forwarded-Proto header is not available in our setup. Instead $_SERVER['HTTP_FRONT_END_HTTPS'] is set to "on".