React to docs location move

README.md

@@ -9,7 +9,7 @@ We expect YARP to ship as a library and project template that together provide a
 
 # Getting started
 
-- See our [Getting Started](https://microsoft.github.io/reverse-proxy/articles/getting-started.html) docs.
+- See our [Getting Started](https://learn.microsoft.com/aspnet/core/fundamentals/servers/yarp/getting-started) docs.
 - Try our [previews](https://github.com/dotnet/yarp/releases).
 - Try our latest [daily build](/docs/DailyBuilds.md).
 

YARP.sln

@@ -23,10 +23,6 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "test", "test", "{0631147E-3
 EndProject
 Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "src", "src", "{6CBE18D4-64E9-492B-BB02-58CD57126C10}"
 EndProject
-Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "docs", "docs", "{BC344A50-8F81-4762-9F4B-12714693144B}"
-EndProject
-Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "docfx", "docs\docfx\docfx.csproj", "{7F6D4710-07D1-49D0-8EAE-675A3A9B50E3}"
-EndProject
 Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "ReverseProxy.Auth.Sample", "samples\ReverseProxy.Auth.Sample\ReverseProxy.Auth.Sample.csproj", "{354F2755-A090-4735-A657-726FB6DA92CD}"
 EndProject
 Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Yarp.ReverseProxy.FunctionalTests", "test\ReverseProxy.FunctionalTests\Yarp.ReverseProxy.FunctionalTests.csproj", "{31089146-71DA-45C2-ACA6-EA1E2C916FD0}"
@@ -134,14 +130,6 @@ Global
 		{11D098B2-7116-4F37-817A-E496B8F15C76}.Release|Any CPU.Build.0 = Release|Any CPU
 		{11D098B2-7116-4F37-817A-E496B8F15C76}.Release|x64.ActiveCfg = Release|Any CPU
 		{11D098B2-7116-4F37-817A-E496B8F15C76}.Release|x64.Build.0 = Release|Any CPU
-		{7F6D4710-07D1-49D0-8EAE-675A3A9B50E3}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
-		{7F6D4710-07D1-49D0-8EAE-675A3A9B50E3}.Debug|Any CPU.Build.0 = Debug|Any CPU
-		{7F6D4710-07D1-49D0-8EAE-675A3A9B50E3}.Debug|x64.ActiveCfg = Debug|Any CPU
-		{7F6D4710-07D1-49D0-8EAE-675A3A9B50E3}.Debug|x64.Build.0 = Debug|Any CPU
-		{7F6D4710-07D1-49D0-8EAE-675A3A9B50E3}.Release|Any CPU.ActiveCfg = Release|Any CPU
-		{7F6D4710-07D1-49D0-8EAE-675A3A9B50E3}.Release|Any CPU.Build.0 = Release|Any CPU
-		{7F6D4710-07D1-49D0-8EAE-675A3A9B50E3}.Release|x64.ActiveCfg = Release|Any CPU
-		{7F6D4710-07D1-49D0-8EAE-675A3A9B50E3}.Release|x64.Build.0 = Release|Any CPU
 		{354F2755-A090-4735-A657-726FB6DA92CD}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
 		{354F2755-A090-4735-A657-726FB6DA92CD}.Debug|Any CPU.Build.0 = Debug|Any CPU
 		{354F2755-A090-4735-A657-726FB6DA92CD}.Debug|x64.ActiveCfg = Debug|Any CPU
@@ -382,7 +370,6 @@ Global
 		{568EF8AE-7624-490D-A19F-C25D076FF091} = {6CBE18D4-64E9-492B-BB02-58CD57126C10}
 		{3B188E4C-C926-4BED-94F3-0E83668FBAB0} = {0631147E-34BB-456D-B214-5B202C516D5C}
 		{11D098B2-7116-4F37-817A-E496B8F15C76} = {149C61A2-D9F8-49B9-9F9B-3C953FEF53AA}
-		{7F6D4710-07D1-49D0-8EAE-675A3A9B50E3} = {BC344A50-8F81-4762-9F4B-12714693144B}
 		{354F2755-A090-4735-A657-726FB6DA92CD} = {149C61A2-D9F8-49B9-9F9B-3C953FEF53AA}
 		{31089146-71DA-45C2-ACA6-EA1E2C916FD0} = {0631147E-34BB-456D-B214-5B202C516D5C}
 		{F2547357-FB2F-4944-842F-D33D1E7A17FC} = {149C61A2-D9F8-49B9-9F9B-3C953FEF53AA}

docs/DailyBuilds.md

@@ -23,7 +23,7 @@ If you want to download the latest daily build and use it in a project, then you
 
   *NOTE: This NuGet.Config should be with your application unless you want nightly packages to potentially start being restored for other apps on the machine.*
 
-Then follow the [Getting Started](https://microsoft.github.io/reverse-proxy/articles/getting-started.html) guide to set up a project and add the nuget package dependency. Note daily builds use a higher preview version than given in the docs.
+Then follow the [Getting Started](https://learn.microsoft.com/aspnet/core/fundamentals/servers/yarp/getting-started) guide to set up a project and add the nuget package dependency. Note daily builds use a higher preview version than given in the docs.
 
 Some features, such as new target frameworks, may require prerelease tooling builds for Visual Studio.
 These are available in the [Visual Studio Preview](https://www.visualstudio.com/vs/preview/).

docs/README.md

@@ -4,4 +4,5 @@ This folder contains:
 
 * [Design Notes](designs/) - These are the design notes used to guide our development. They aren't designed to be usage guides but may help contributors in understanding why some patterns were used.
 * [Operations](operations/) - These are operational docs for running releases and other infrastructure related to the project.
-* [Public Usage Docs](docfx/) - This is a [docfx](https://dotnet.github.com/docfx) project that generates our public docs site [microsoft.github.io/reverse-proxy](https://microsoft.github.io/reverse-proxy). Any commit to `main` will trigger the [GitHub Action](../.github/workflows/docfx_build.yml) to rebuild the docs site and push it to the `gh-pages` branch.
+
+Public documentation is available at [learn.microsoft.com](https://learn.microsoft.com/aspnet/core/fundamentals/servers/yarp/getting-started).

docs/designs/config.md

@@ -1,5 +1,8 @@
 # Config based proxy apps
 
+> [!CAUTION]
+> These are archived design discussions. Information may be outdated and inaccurate.
+
 RE: https://github.com/dotnet/yarp/issues/9
 
 Config based proxies are common and we'll need to support at least basic proxy scenarios from config. Here are some initial considerations:
@@ -14,7 +17,7 @@ Config based proxies are common and we'll need to support at least basic proxy s
 
 We have three relevant components that already have config systems: Kestrel, UrlRewrite, and ReverseProxy.
 
-- [Kestrel](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#endpoint-configuration)
+- [Kestrel](https://learn.microsoft.com/aspnet/core/fundamentals/servers/kestrel/endpoints)
 - [UrlRewrite](https://github.com/dotnet/aspnetcore/blob/f4d81e3af2b969744a57d76d4d622036ac514a6a/src/Middleware/Rewrite/sample/UrlRewrite.xml#L1-L11)
 - [ReverseProxy](https://github.com/dotnet/yarp/blob/b2cf5bdddf7962a720672a75f2e93913d16dfee7/samples/IslandGateway.Sample/appsettings.json#L10-L34)
 

docs/designs/route-extensibility.md

@@ -1,5 +1,8 @@
 ## Problem Statement
 
+> [!CAUTION]
+> These are archived design discussions. Information may be outdated and inaccurate.
+
 Today if you want to extend the route or clusters, you can only do it through the metadata property on each, which is a Dictionary<string, string>. If you want to be able to have structured data its not possible without you forcing it into a string and then parsing it when needed. There are scenarios like A/B testing, or authenticating with back end servers (not pass thru) where you want to be able to store a structure of data in config, and have it available at runtime on the route/cluster objects.
 
 If we want there to be pre-built extensions to YARP (#1714), then there needs to be a way for each of the extensions to have its own config data on routes and clusters, and for them to not step on each others toes.

docs/designs/yarp-tunneling.md

@@ -1,9 +1,12 @@
 # YARP Tunneling
 
+> [!CAUTION]
+> These are archived design discussions. Information may be outdated and inaccurate.
+
 ## Introduction
 While many organizations are moving their computing to the cloud, there are occasions where you need to be able to run some services in a local datacenter. The problem then is if you need to be able to communicate with those services from the cloud. Creating a VPN network connection to Azure or other cloud provider is possible, but usually involves a lot of red tape and configuration complexity as the two networks need to be integrated.
 
-If all that the cloud needs to access is resources that are exposed over http, then a simpler solution is to have a gateway that can route traffic to the remote resource. Additionally, outbound connections over http(s) are not usually blocked, so having a on-prem gateway make an outbound connection to the cloud, is the easiest way to establish the route. This is the basis behind the [Azure Relay](https://docs.microsoft.com/en-us/azure/azure-relay/relay-what-is-it) service offering.
+If all that the cloud needs to access is resources that are exposed over http, then a simpler solution is to have a gateway that can route traffic to the remote resource. Additionally, outbound connections over http(s) are not usually blocked, so having a on-prem gateway make an outbound connection to the cloud, is the easiest way to establish the route. This is the basis behind the [Azure Relay](https://learn.microsoft.com/azure/azure-relay/relay-what-is-it) service offering.
 
 That is the principle of the tunnel feature for YARP. You operate two instances of the YARP proxy service, configured as a tunnel. The advantage over Azure Relay is that using a reverse proxy as an on-prem gateway means that both cloud and back end services can be used without needing to update the application other than addresses. This is particularly useful for services that may have been written by a 3rd party, or are no longer under active development, and so making changes to the configuration is complicated and expensive. Relay requires the sender and reciever to be updated to use its connection protocol.