Merge pull request NuGet#1762 from Youssef1313/http-https

http -> https

Author: karann-msft

docs/api/registration-base-url-resource.md

@@ -126,7 +126,7 @@ The `lower` and `upper` bounds of the page object are useful when the metadata f
 These bounds can be used to fetch the only registration page needed. The version strings adhere to
 [NuGet's version rules](../concepts/package-versioning.md). The version strings are normalized and do not include
 build metadata. As with all versions in the NuGet ecosystem, comparison of version strings is implemented using
-[SemVer 2.0.0's version precedence rules](http://semver.org/spec/v2.0.0.html#spec-item-11).
+[SemVer 2.0.0's version precedence rules](https://semver.org/spec/v2.0.0.html#spec-item-11).
 
 The `parent` property will only appear if the registration page object has the `items` property.
 

docs/api/tools-json.md

@@ -31,7 +31,7 @@ The endpoint can be fetched using the `GET` method:
 
 	GET https://dist.nuget.org/tools.json
 
-The [JSON schema](http://json-schema.org/) for the endpoint is available here:
+The [JSON schema](https://json-schema.org/) for the endpoint is available here:
 
 	GET https://dist.nuget.org/tools.schema.json
 

docs/concepts/Package-Versioning.md

@@ -27,7 +27,7 @@ A specific version number is in the form *Major.Minor.Patch[-Suffix]*, where the
 - *Major*: Breaking changes
 - *Minor*: New features, but backwards compatible
 - *Patch*: Backwards compatible bug fixes only
-- *-Suffix* (optional): a hyphen followed by a string denoting a pre-release version (following the [Semantic Versioning or SemVer 1.0 convention](http://semver.org/spec/v1.0.0.html)).
+- *-Suffix* (optional): a hyphen followed by a string denoting a pre-release version (following the [Semantic Versioning or SemVer 1.0 convention](https://semver.org/spec/v1.0.0.html)).
 
 **Examples:**
 
@@ -50,7 +50,7 @@ That said, package developers generally follow recognized naming conventions:
 - `-rc`: Release candidate, typically a release that's potentially final (stable) unless significant bugs emerge.
 
 > [!Note]
-> NuGet 4.3.0+ supports [SemVer 2.0.0](http://semver.org/spec/v2.0.0.html), which supports pre-release numbers with dot notation, as in *1.0.1-build.23*. Dot notation is not supported with NuGet versions before 4.3.0. You can use a form like *1.0.1-build23*.
+> NuGet 4.3.0+ supports [SemVer 2.0.0](https://semver.org/spec/v2.0.0.html), which supports pre-release numbers with dot notation, as in *1.0.1-build.23*. Dot notation is not supported with NuGet versions before 4.3.0. You can use a form like *1.0.1-build23*.
 
 When resolving package references and multiple package versions differ only by suffix, NuGet chooses a version without a suffix first, then applies precedence to pre-release versions in reverse alphabetical order. For example, the following versions would be chosen in the exact order shown:
 
@@ -65,7 +65,7 @@ When resolving package references and multiple package versions differ only by s
 
 ## Semantic Versioning 2.0.0
 
-With NuGet 4.3.0+ and Visual Studio 2017 version 15.3+, NuGet supports [Semantic Versioning 2.0.0](http://semver.org/spec/v2.0.0.html).
+With NuGet 4.3.0+ and Visual Studio 2017 version 15.3+, NuGet supports [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html).
 
 Certain semantics of SemVer v2.0.0 are not supported in older clients. NuGet considers a package version to be SemVer v2.0.0 specific if either of the following statements is true:
 

docs/consume-packages/Finding-and-Choosing-Packages.md

@@ -9,7 +9,7 @@ ms.topic: conceptual
 
 # Finding and evaluating NuGet packages for your project
 
-When starting any .NET project, or whenever you identify a functional need for your app or service, you can save yourself lots of time and trouble by using existing NuGet packages that fulfill that need. These packages can come from the public collection on [nuget.org](http://www.nuget.org/packages/), or a private source that's provided by your organization or another third party.
+When starting any .NET project, or whenever you identify a functional need for your app or service, you can save yourself lots of time and trouble by using existing NuGet packages that fulfill that need. These packages can come from the public collection on [nuget.org](https://www.nuget.org/packages/), or a private source that's provided by your organization or another third party.
 
 ## Finding packages
 

docs/consume-packages/Team-Foundation-Build.md

@@ -26,7 +26,7 @@ If you're using Visual Studio Team Services or Team Foundation Server 2013 with
 
 An advantage of using NuGet is that you can use it to avoid checking in binaries to your version control system.
 
-This is especially interesting if you are using a [distributed version control](http://en.wikipedia.org/wiki/Distributed_revision_control) system like git because developers need to clone the entire repository, including the full history, before they can start working locally. Checking in binaries can cause significant repository bloat as binary files are typically stored without delta compression.
+This is especially interesting if you are using a [distributed version control](https://en.wikipedia.org/wiki/Distributed_revision_control) system like git because developers need to clone the entire repository, including the full history, before they can start working locally. Checking in binaries can cause significant repository bloat as binary files are typically stored without delta compression.
 
 NuGet has supported [restoring packages](../consume-packages/package-restore.md) as part of the build for a long time now. The previous implementation had a chicken-and-egg problem for packages that want to extend the build process because NuGet restored packages while building the project. However, MSBuild doesn't allow extending the build during the build; one could argue that this an issue in MSBuild but I would argue that this is an inherent problem. Depending on which aspect you need to extend it might be too late to register by the time your package is restored.
 
@@ -45,7 +45,7 @@ The following demo project shows how to set up the build in such a way that the
 
 ## Repository structure
 
-Our demo project is a simple command line tool that uses the command line argument to query Bing. It targets the .NET Framework 4 and uses many of the [BCL packages](http://www.nuget.org/profiles/dotnetframework/) ([Microsoft.Net.Http](http://www.nuget.org/packages/Microsoft.Net.Http), [Microsoft.Bcl](http://www.nuget.org/packages/Microsoft.Bcl), [Microsoft.Bcl.Async](http://www.nuget.org/packages/Microsoft.Bcl.Async), and [Microsoft.Bcl.Build](http://www.nuget.org/packages/Microsoft.Bcl.Build)).
+Our demo project is a simple command line tool that uses the command line argument to query Bing. It targets the .NET Framework 4 and uses many of the [BCL packages](https://www.nuget.org/profiles/dotnetframework/) ([Microsoft.Net.Http](https://www.nuget.org/packages/Microsoft.Net.Http), [Microsoft.Bcl](https://www.nuget.org/packages/Microsoft.Bcl), [Microsoft.Bcl.Async](https://www.nuget.org/packages/Microsoft.Bcl.Async), and [Microsoft.Bcl.Build](https://www.nuget.org/packages/Microsoft.Bcl.Build)).
 
 The structure of the repository looks as follows:
 

docs/consume-packages/install-use-packages-powershell.md

@@ -167,9 +167,9 @@ For more details, refer to [Windows PowerShell Profiles](https://technet.microso
 
 ## Use the nuget.exe CLI in the console
 
-To make the [`nuget.exe` CLI](../reference/nuget-exe-cli-reference.md) available in the Package Manager Console, install the [NuGet.CommandLine](http://www.nuget.org/packages/NuGet.CommandLine/) package from the console:
+To make the [`nuget.exe` CLI](../reference/nuget-exe-cli-reference.md) available in the Package Manager Console, install the [NuGet.CommandLine](https://www.nuget.org/packages/NuGet.CommandLine/) package from the console:
 
 ```ps
-# Other versions are available, see http://www.nuget.org/packages/NuGet.CommandLine/
+# Other versions are available, see https://www.nuget.org/packages/NuGet.CommandLine/
 Install-Package NuGet.CommandLine -Version 4.4.1
 ```

docs/create-packages/Creating-Localized-Packages.md

@@ -66,7 +66,7 @@ With these folders in place, you then reference all the files in your `.nuspec`:
 </package>
 ```
 
-One example package that uses this approach is [Microsoft.Data.OData 5.4.0](http://nuget.org/packages/Microsoft.Data.OData/5.4.0).
+One example package that uses this approach is [Microsoft.Data.OData 5.4.0](https://nuget.org/packages/Microsoft.Data.OData/5.4.0).
 
 ### Advantages and disadvantages (localized resource assemblies)
 
@@ -114,11 +114,11 @@ When all of these conventions are met, NuGet will recognize the package as a sat
 
 You would create additional satellite assemblies in the same way for each supported language. For an example, examine the set of ASP.NET MVC packages:
 
-- [Microsoft.AspNet.Mvc](http://nuget.org/packages/Microsoft.AspNet.Mvc) (English primary)
-- [Microsoft.AspNet.Mvc.de](http://nuget.org/packages/Microsoft.AspNet.Mvc.de) (German)
-- [Microsoft.AspNet.Mvc.ja](http://nuget.org/packages/Microsoft.AspNet.Mvc.ja) (Japanese)
-- [Microsoft.AspNet.Mvc.zh-Hans](http://nuget.org/packages/Microsoft.AspNet.Mvc.zh-Hans) (Chinese (Simplified))
-- [Microsoft.AspNet.Mvc.zh-Hant](http://nuget.org/packages/Microsoft.AspNet.Mvc.zh-Hant) (Chinese (Traditional))
+- [Microsoft.AspNet.Mvc](https://nuget.org/packages/Microsoft.AspNet.Mvc) (English primary)
+- [Microsoft.AspNet.Mvc.de](https://nuget.org/packages/Microsoft.AspNet.Mvc.de) (German)
+- [Microsoft.AspNet.Mvc.ja](https://nuget.org/packages/Microsoft.AspNet.Mvc.ja) (Japanese)
+- [Microsoft.AspNet.Mvc.zh-Hans](https://nuget.org/packages/Microsoft.AspNet.Mvc.zh-Hans) (Chinese (Simplified))
+- [Microsoft.AspNet.Mvc.zh-Hant](https://nuget.org/packages/Microsoft.AspNet.Mvc.zh-Hant) (Chinese (Traditional))
 
 ### Summary of required conventions
 

docs/create-packages/Creating-a-Package.md

@@ -271,9 +271,9 @@ The package identifier (`<id>` element) and the version number (`<version>` elem
 
 > The following series of brief blog posts are also helpful to understand versioning:
 >
-> - [Part 1: Taking on DLL Hell](http://blog.davidebbo.com/2011/01/nuget-versioning-part-1-taking-on-dll.html)
-> - [Part 2: The core algorithm](http://blog.davidebbo.com/2011/01/nuget-versioning-part-2-core-algorithm.html)
-> - [Part 3: Unification via Binding Redirects](http://blog.davidebbo.com/2011/01/nuget-versioning-part-3-unification-via.html)
+> - [Part 1: Taking on DLL Hell](https://blog.davidebbo.com/2011/01/nuget-versioning-part-1-taking-on-dll.html)
+> - [Part 2: The core algorithm](https://blog.davidebbo.com/2011/01/nuget-versioning-part-2-core-algorithm.html)
+> - [Part 3: Unification via Binding Redirects](https://blog.davidebbo.com/2011/01/nuget-versioning-part-3-unification-via.html)
 
 ## Add a readme and other files
 

docs/create-packages/Prerelease-Packages.md

@@ -51,7 +51,7 @@ By default, NuGet does not include pre-release versions when working with packag
 
 ## Semantic versioning
 
-The [Semantic Versioning or SemVer convention](http://semver.org/spec/v1.0.0.html) describes how to utilize strings in version numbers to convey the meaning of the underlying code.
+The [Semantic Versioning or SemVer convention](https://semver.org/spec/v1.0.0.html) describes how to utilize strings in version numbers to convey the meaning of the underlying code.
 
 In this convention, each version has three parts, `Major.Minor.Patch`, with the following meaning:
 
@@ -68,7 +68,7 @@ With this in mind, it's generally good to follow recognized naming conventions s
 - `-rc`: Release candidate, typically a release that's potentially final (stable) unless significant bugs emerge.
 
 > [!Note]
-> NuGet 4.3.0+ supports [Semantic Versioning v2.0.0](http://semver.org/spec/v2.0.0.html), which supports pre-release numbers with dot notation, as in `1.0.1-build.23`. Dot notation is not supported with NuGet versions before 4.3.0. In earlier versions of NuGet, you could use a form like `1.0.1-build23` but this was always considered a pre-release version.
+> NuGet 4.3.0+ supports [Semantic Versioning v2.0.0](https://semver.org/spec/v2.0.0.html), which supports pre-release numbers with dot notation, as in `1.0.1-build.23`. Dot notation is not supported with NuGet versions before 4.3.0. In earlier versions of NuGet, you could use a form like `1.0.1-build23` but this was always considered a pre-release version.
 
 Whatever suffixes you use, however, NuGet will give them precedence in reverse alphabetical order:
 

docs/create-packages/Supporting-Multiple-Target-Frameworks.md

@@ -146,8 +146,8 @@ The following example shows different variations of the `<group>` element:
 
 When packaging libraries targeting the Portable Class Library it can be tricky to determine which NuGet target you should use in your folder names and `.nuspec` file, especially if targeting only a subset of the PCL. The following external resources will help you with this:
 
-- [Framework profiles in .NET](http://blog.stephencleary.com/2012/05/framework-profiles-in-net.html) (stephencleary.com)
-- [Portable Class Library profiles](http://embed.plnkr.co/03ck2dCtnJogBKHJ9EjY/preview) (plnkr.co): Table enumerating PCL profiles and their equivalent NuGet targets
+- [Framework profiles in .NET](https://blog.stephencleary.com/2012/05/framework-profiles-in-net.html) (stephencleary.com)
+- [Portable Class Library profiles](https://embed.plnkr.co/03ck2dCtnJogBKHJ9EjY/preview) (plnkr.co): Table enumerating PCL profiles and their equivalent NuGet targets
 - [Portable Class Library profiles tool](https://github.com/StephenCleary/PortableLibraryProfiles) (github.com): command line tool for determining PCL profiles available on your system
 
 ## Content files and PowerShell scripts

docs/create-packages/includes/choose-package-id.md

@@ -13,6 +13,6 @@ The package identifier and the version number are the two most important values
 
 > For information on dependency resolution, see [Dependency resolution with PackageReference](../../concepts/dependency-resolution.md#dependency-resolution-with-packagereference). For older information that may also be helpful to better understand versioning, see this series of blog posts.
 >
-> - [Part 1: Taking on DLL Hell](http://blog.davidebbo.com/2011/01/nuget-versioning-part-1-taking-on-dll.html)
-> - [Part 2: The core algorithm](http://blog.davidebbo.com/2011/01/nuget-versioning-part-2-core-algorithm.html)
-> - [Part 3: Unification via Binding Redirects](http://blog.davidebbo.com/2011/01/nuget-versioning-part-3-unification-via.html)
+> - [Part 1: Taking on DLL Hell](https://blog.davidebbo.com/2011/01/nuget-versioning-part-1-taking-on-dll.html)
+> - [Part 2: The core algorithm](https://blog.davidebbo.com/2011/01/nuget-versioning-part-2-core-algorithm.html)
+> - [Part 3: Unification via Binding Redirects](https://blog.davidebbo.com/2011/01/nuget-versioning-part-3-unification-via.html)

docs/hosting-packages/NuGet-Server.md

@@ -48,7 +48,7 @@ If you have further questions about NuGet.Server, create an issue on [https://gi
 
 1. Click on **here** in the area outlined above to see the OData feed of packages.
 
-1. The first time you run the application, NuGet.Server restructures the `Packages` folder to contain a folder for each package. This matches the [local storage layout](http://blog.nuget.org/20151118/nuget-3.3.html#folder-based-repository-commands) introduced with NuGet 3.3 to improve performance. When adding more packages, continue to follow this structure.
+1. The first time you run the application, NuGet.Server restructures the `Packages` folder to contain a folder for each package. This matches the [local storage layout](https://blog.nuget.org/20151118/nuget-3.3.html#folder-based-repository-commands) introduced with NuGet 3.3 to improve performance. When adding more packages, continue to follow this structure.
 
 1. Once you've tested your local deployment, deploy the application to any other internal or external site as needed.
 

docs/hosting-packages/Overview.md

@@ -26,11 +26,11 @@ There are also several other NuGet hosting products such as [Azure Artifacts](ht
 - [Cloudsmith](https://cloudsmith.io/l/nuget-feed/), a fully managed package management SaaS
 - [GitHub package registry](https://help.github.com/articles/configuring-nuget-for-use-with-github-package-registry)
 - [LiGet](https://github.com/ai-traders/liget), an open-source implementation of NuGet V2 server that runs on kestrel in docker
-- [MyGet](http://myget.org)
-- [Nexus](http://www.sonatype.org/nexus/) from Sonatype.
-- [NuGet Server (Open Source)](http://nuget-server.net), an open-source implementation similar to Inedo's NuGet Server
+- [MyGet](https://myget.org)
+- [Nexus](https://www.sonatype.org/nexus/) from Sonatype.
+- [NuGet Server (Open Source)](https://github.com/svenkle/nuget-server), an open-source implementation similar to Inedo's NuGet Server
 - [NuGet Server](http://nugetserver.net/), a community project from Inedo
-- [ProGet](http://inedo.com/proget) from Inedo
+- [ProGet](https://inedo.com/proget) from Inedo
 - [Sleet](https://github.com/emgarten/sleet), an open-source NuGet V3 static feed generator
 - [TeamCity](https://www.jetbrains.com/teamcity/) from JetBrains.
 

docs/includes/install-cli.md

@@ -11,7 +11,7 @@
 
 Behaviors may vary slightly by OS distribution.
 
-1. Install [Mono 4.4.2 or later](http://www.mono-project.com/docs/getting-started/install/).
+1. Install [Mono 4.4.2 or later](https://www.mono-project.com/docs/getting-started/install/).
 
 1. Execute the following command at a shell prompt:
 

docs/install-nuget-client-tools.md

@@ -41,7 +41,7 @@ To learn how to use basic commands with the dotnet CLI, see [Install and use pac
 
 ### nuget.exe CLI
 
-The `nuget.exe` CLI, `nuget.exe`, is the command-line utility for Windows that provides all NuGet capabilities; it can also be run on Mac OSX and Linux using [Mono](http://www.mono-project.com/docs/getting-started/install/) with some limitations.
+The `nuget.exe` CLI, `nuget.exe`, is the command-line utility for Windows that provides all NuGet capabilities; it can also be run on Mac OSX and Linux using [Mono](https://www.mono-project.com/docs/getting-started/install/) with some limitations.
 
 To learn how to use basic commands with the `nuget.exe` CLI, see [Install and use packages using the nuget.exe CLI](consume-packages/install-use-packages-nuget-cli.md).
 

docs/nuget-org/Publish-a-package.md

@@ -110,7 +110,7 @@ From here you have several options:
 1. Add an owner under **Add Owner** by entering their user name, a message, and selecting **Add**. This action sends an email to that new co-owner with a confirmation link. Once confirmed, that person has full permissions to add and remove owners. (Until confirmed, the **Current Owners** section indicates pending approval for that person.)
 1. To transfer ownership (as when ownership changes or a package was published under the wrong account), add the new owner, and once they've confirmed ownership they can remove you from the list.
 
-To assign ownership to a company or group, create a nuget.org account using an email alias that is forwarded to the appropriate team members. For example, various Microsoft ASP.NET packages are co-owned by the [microsoft](http://nuget.org/profiles/microsoft) and [aspnet](http://nuget.org/profiles/aspnet) accounts, which simply such aliases.
+To assign ownership to a company or group, create a nuget.org account using an email alias that is forwarded to the appropriate team members. For example, various Microsoft ASP.NET packages are co-owned by the [microsoft](https://nuget.org/profiles/microsoft) and [aspnet](https://nuget.org/profiles/aspnet) accounts, which simply such aliases.
 
 ### Recovering package ownership