[WIP] Broaden HTTPS Check

[jbh]

Because:

• It is common for end users to use ports other than 443 for HTTPS
• Mature systems, like IBM i, like to uppercase values

Provide a narrative description of what you are trying to accomplish:

• [x] Are you fixing a bug?
  • [x] Detail how the bug is invoked currently. If you try building an API with HTTPS without using 443, the self links that are built and returned will be HTTP. If you try building an API on IBM i, even using 443, it will still send HTTP, because IBM i will uppercase ON and HTTPS values for the SERVER properties.
  • [x] Detail the original, incorrect behavior. As stated above, the self links that are generated in API responses will be HTTP instead of HTTPS.
  • [x] Detail the new, expected behavior. Self links will properly send HTTPS.
  • [x] Base your feature on the master branch, and submit against that branch.
  • [ ] Add a regression test that demonstrates the bug, and proves the fix. This is difficult to accomplish, as the test I am doing runs on IBM i.
  • [ ] Add a CHANGELOG.md entry for the fix. TODO

[jbh]

Forgot to mention that this will resolve #194.

[jbh]

All checks failed? Ouch.

[froschdesign]

@jbh

It is common for end users to use ports other than 443 for HTTPS.

"common" – I do not think so; and if it were so, then something more must be change in the class and in some other components too. (e.g. zend-uri, zend-diactoros)

Mature systems, like IBM i, like to uppercase values

Sounds conclusive. We need unit tests to cover these changes. Thanks in advance!

All checks failed? Ouch.

Right, see the results on Travis: https://travis-ci.org/zendframework/zend-view/jobs/611967352#L439-L447

[jbh]

@froschdesign I work with many enterprise agencies, and they have plenty of internal, and even some external applications that they use HTTPS on different ports for. They would be pretty offended to hear that isn't common... This is a deal breaker for them when they try to use Apigility.

I'm trying to find a decent way to handle the tests. Thanks for the input, and pointing me to the proper error in Travis.

Edited to add a question If the maintainers insist I do not remove the 443 check, which I can agree is non-standard (not uncommon, though) what do they suggest I do to support applications built with HTTPS on the non-standard port?

[weierophinney]

@froschdesign and @jbh —

The way we handle it in Diactoros (per the PSR-7 specification) is to omit the port when it corresponds to the default port for the scheme used. So, for HTTP, you omit :80, and for HTTPS, you omit :443.

The IETF says that you can use the port in all cases, but suggests that it should be omitted when it is the default, which is why we went that route for Diactoros.

That's all that needs to happen here.

[weierophinney]

This repository has been closed and moved to laminas/laminas-view; a new issue has been opened at https://github.com/laminas/laminas-view/issues/1.

[weierophinney]

This repository has been moved to laminas/laminas-view. If you feel that this patch is still relevant, please re-open against that repository, and reference this issue. To re-open, we suggest the following workflow:

• Squash all commits in your branch (git rebase -i origin/{branch})
• Make a note of all changed files (`git diff --name-only origin/{branch}...HEAD
• Run the laminas/laminas-migration tool on the code.
• Clone laminas/laminas-view to another directory.
• Copy the files from the second bullet point to the clone of laminas/laminas-view.
• In your clone of laminas/laminas-view, commit the files, push to your fork, and open the new PR. We will be providing tooling via laminas/laminas-migration soon to help automate the process.