URL Cleanup (#9)

* URL Cleanup

This commit updates URLs to prefer the https protocol. Redirects are not followed to avoid accidentally expanding intentionally shortened URLs (i.e. if using a URL shortener).

# Fixed URLs

## Fixed But Review Recommended
These URLs were fixed, but the https status was not OK. However, the https status was the same as the http request or http redirected to an https URL, so they were migrated. Your review is recommended.

* http://cla2.dotnetfoundation.org (UnknownHostException) with 1 occurrences migrated to:
  https://cla2.dotnetfoundation.org ([https](https://cla2.dotnetfoundation.org) result UnknownHostException).

## Fixed Success
These URLs were switched to an https URL with a 2xx status. While the status was successful, your review is still recommended.

* http://en.wikipedia.org/wiki/Contributor_License_Agreement with 1 occurrences migrated to:
  https://en.wikipedia.org/wiki/Contributor_License_Agreement ([https](https://en.wikipedia.org/wiki/Contributor_License_Agreement) result 200).
* http://en.wikipedia.org/wiki/Indent_style with 1 occurrences migrated to:
  https://en.wikipedia.org/wiki/Indent_style ([https](https://en.wikipedia.org/wiki/Indent_style) result 200).
* http://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning with 1 occurrences migrated to:
  https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning ([https](https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning) result 200).
* http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html with 1 occurrences migrated to:
  https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html ([https](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) result 200).
* http://www.dotnetfoundation.org/code-of-conduct with 2 occurrences migrated to:
  https://www.dotnetfoundation.org/code-of-conduct ([https](https://www.dotnetfoundation.org/code-of-conduct) result 200).
* http://contributor-covenant.org/ with 1 occurrences migrated to:
  https://contributor-covenant.org/ ([https](https://contributor-covenant.org/) result 301).

* Update contributing-license.md

* Update contributing-license.md

CONTRIBUTING.md

@@ -1,5 +1,5 @@
 # Contributing
 
-Please note that the Steeltoe project has adopted the [Contributor Code of Conduct](http://www.dotnetfoundation.org/code-of-conduct). By participating in this project you agree to abide by its terms.
+Please note that the Steeltoe project has adopted the [Contributor Code of Conduct](https://www.dotnetfoundation.org/code-of-conduct). By participating in this project you agree to abide by its terms.
 
 For more information on how to get involved and to view our project governance model, please read our [contributing guidelines](project-docs/contributing.md).

README.md

@@ -104,8 +104,8 @@ The Steeltoe project welcomes contributions both by filing issues and through PR
 
 Check out the [contributing](https://github.com/SteeltoeOSS/Home/tree/master/project-docs/contributing.md) page to see how you can get involved and contribute to Steeltoe.
 
-Also its worth noting, the Steeltoe project has adopted the code of conduct defined by the [Contributor Covenant](http://contributor-covenant.org/).
-If you'd like more information, see the [.NET Foundation Code of Conduct](http://www.dotnetfoundation.org/code-of-conduct) write-up.
+Also its worth noting, the Steeltoe project has adopted the code of conduct defined by the [Contributor Covenant](https://contributor-covenant.org/).
+If you'd like more information, see the [.NET Foundation Code of Conduct](https://www.dotnetfoundation.org/code-of-conduct) write-up.
 
 ## Governance Model
 

project-docs/contributing-code-style.md

@@ -6,7 +6,7 @@ This guide provides instructions which you can follow that will help you during
 
  While we likely are not completely consistent throughout our code base, we are striving to be better, so please try to follow our coding guidelines. The general set of rules we try to follow is to use "Visual Studio defaults".  As an FYI, most of these guidelines come from the `corefx` C# coding style guide.
 
-1. We use [Allman style](http://en.wikipedia.org/wiki/Indent_style#Allman_style) braces, where each brace begins on a new line. A single line statement block can go without braces but the block must be properly indented on its own line and it must not be nested in other statement blocks that use braces.
+1. We use [Allman style](https://en.wikipedia.org/wiki/Indent_style#Allman_style) braces, where each brace begins on a new line. A single line statement block can go without braces but the block must be properly indented on its own line and it must not be nested in other statement blocks that use braces.
 1. We use four spaces of indentation (no tabs).
 1. We use `_camelCase` for internal and private fields and use `readonly` where possible. Prefix instance fields with `_`, static fields with `s_` and thread static fields with `t_`. When used on static fields, `readonly` should come after `static` (i.e. `static readonly` not `readonly static`).
 1. We avoid `this.` unless absolutely necessary.

project-docs/contributing-license.md

@@ -1,8 +1,8 @@
 # Contributor License Agreement
 
-You must sign a [.NET Foundation Contribution License Agreement (CLA)](http://cla2.dotnetfoundation.org) before your Pull Request will be merged. This is a one-time requirement for projects in the .NET Foundation. You can read more about [Contribution License Agreements (CLA)](http://en.wikipedia.org/wiki/Contributor_License_Agreement) on Wikipedia.
+You must sign a [.NET Foundation Contribution License Agreement (CLA)](https://cla.dotnetfoundation.org) before your Pull Request will be merged. This is a one-time requirement for projects in the .NET Foundation. You can read more about [Contribution License Agreements (CLA)](https://en.wikipedia.org/wiki/Contributor_License_Agreement) on Wikipedia.
 
-The agreement: [net-foundation-contribution-license-agreement.pdf](https://cla2.dotnetfoundation.org/cladoc/net-foundation-contribution-license-agreement.pdf)
+The agreement: [net-foundation-contribution-license-agreement.pdf](https://cla.dotnetfoundation.org/cladoc/net-foundation-contribution-license-agreement.pdf)
 
 You don't have to do this up-front. You can simply clone, fork, and submit your pull-request as usual. When your pull-request is created, it is classified by a CLA bot. If the change is trivial (for example, you just fixed a typo), then the PR is labelled with cla-not-required. Otherwise it's classified as cla-required. Once you signed a CLA, the current and all future pull-requests will be labelled as cla-signed.
 

project-docs/contributing-workflow.md

@@ -29,7 +29,7 @@ You should **never** work on a clone of `master`, and you should **never** send
 
 While you're working away in your branch it's quite possible that the upstream `dev` branch will be updated. If this happens you should:
 
-1. [Stash](http://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning) any un-committed changes you need to save
+1. [Stash](https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning) any un-committed changes you need to save
 1. `git checkout dev`
 1. `git pull upstream dev`
 1. `git rebase dev myBranch`
@@ -52,7 +52,7 @@ The systems we use for CI (i.e. AppVeyor and Travis) will automatically perform
 
 ## Commit Messages
 
-Please format commit messages as follows (based on [A Note About Git Commit Messages](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)):
+Please format commit messages as follows (based on [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)):
 
 ```text
 Summarize change in 50 characters or less