Light Freshness Edit: ASP.NET - host and deploy

[lootle1]

This PR contains freshness updates to the following articles:

• ASP.NET Core Module (ANCM) for IIS
• Common error troubleshooting for Azure App Service and IIS with ASP.NET Core
• Advanced configuration of the ASP.NET Core Module and IIS
• Host ASP.NET Core on Windows with IIS
• Host and deploy ASP.NET Core
• web.config file
• Configure ASP.NET Core to work with proxy servers and load balancers
  Line 314, the link for NGINX: Using the Forwarded header redirects to a generic docs page. I replaced with this article link but wanted to confirm this is what you'd like to replace.

Minor grammar/style updates. Link path updates.

For request details, see 568764

---

Internal previews

📄 File	🔗 Preview link
aspnetcore/host-and-deploy/aspnet-core-module.md	ASP.NET Core Module (ANCM) for IIS
aspnetcore/host-and-deploy/azure-iis-errors-reference.md	Common error troubleshooting for Azure App Service and IIS with ASP.NET Core
aspnetcore/host-and-deploy/iis/advanced.md	Advanced configuration
aspnetcore/host-and-deploy/iis/index.md	Host ASP.NET Core on Windows with IIS
aspnetcore/host-and-deploy/iis/web-config.md	aspnetcore/host-and-deploy/iis/web-config
aspnetcore/host-and-deploy/index.md	Host and deploy ASP.NET Core
aspnetcore/host-and-deploy/proxy-load-balancer.md	Configure ASP.NET Core to work with proxy servers and load balancers

[wadepickett]

Hi @lootle1, I will provide a review as soon as I see this is no longer in draft and intented for review or you ping me for one. Thanks for the contribution!

[wadepickett]

Extending the name of the PR with a bit of detail since we had more than one by the same name.

[lootle1]

@dotnet-policy-service agree company="Microsoft"

[lootle1]

@lootle1 please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@dotnet-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@dotnet-policy-service agree

• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@dotnet-policy-service agree company="Microsoft"

Contributor License Agreement

@dotnet-policy-service agree company="Microsoft"

[wadepickett]

@lootle1, not sure how many files you intend to drop in this PR, but I think 5 is probibly good. We add too many articles with significant changes per PR and it becomes more problematic to revert, or address merge conflict issues in main or later pushed to live. If that messes too much with your process and cuts down on your work groove, I can go with more at a time if its worth the trade off.

[lootle1]

@wadepickett ah sounds good! I was continuing to add to have all the host-and-deploy articles in one PR. I'll stop with this last one I'm working on for this PR and stick with the five articles per moving forward, that's no problem! Overall finding these are in good shape so mostly link replacements and grammar/style updates. Hopefully fairly quick to review!

[lootle1]

@tdykstra @wadepickett this PR is ready for review. Top comment has an overview of the seven articles. I have one specific call out for a link but other than that should be fairly straightforward I believe. Let me know if any change requests, thank you!

[wadepickett]

Suggested change

	To forward the `X-Forwarded-For` and `X-Forwarded-Proto` headers, see <xref:host-and-deploy/linux-nginx#configure-nginx>. For more information, see [NGINX: Using the Forwarded header](https://docs.nginx.com/nginx-gateway-fabric/traffic-management/request-response-headers/).
	To forward the `X-Forwarded-For` and `X-Forwarded-Proto` headers, see <xref:host-and-deploy/linux-nginx#configure-nginx>.

Great that was identified as a dead link. Thanks for looking for a replacement. The original link pointed to the NGINX wiki page about configuring RFC 7239 Forwarded headers in standard NGINX. The replacement link points to NGINX Gateway Fabric documentation (a Kubernetes Gateway API product), which is a completely different product and topic. So that suggested link will not work. I'm not finding a replacment. I think we should remove the "For more information link altogether and just rely on the xref we do have there already.

[wadepickett]

Suggested change

	To forward the `X-Forwarded-For` and `X-Forwarded-Proto` headers, see <xref:host-and-deploy/linux-nginx#configure-nginx>.

For this dead link, there isn't a replacement available that I can find. We can remove the "For more information link altogether and just rely on the xref preceeding it.

[wadepickett]

Suggested change

	## version and Hosting Bundle installer logs
	## Module version and Hosting Bundle installer logs

This breaks the heading semantically and would kinda look like an rendering error. This is about Module version so leave this in I think.

[wadepickett]

Suggested change

A pairing token is used to guarantee that IIS proxied the requests received by Kestrel and didn't come from some other source. The pairing token is created and set into an environment variable (`ASPNETCORE_TOKEN`) by the module. The pairing token is also set into a header (`MS-ASPNETCORE-TOKEN`) on every proxied request. IIS Middleware checks each request it receives to confirm that the pairing token header value matches the environment variable value. If the token values are mismatched, the request is logged and rejected. The pairing token environment variable and the traffic between the module and Kestrel aren't accessible from a location off of the server. Without knowing the pairing token value, a cyberattacker can't submit requests that bypass the check in the IIS Middleware.

A pairing token is used to guarantee that the requests received by Kestrel were proxied by IIS and didn't come from some other source. The pairing token is created and set into an environment variable (`ASPNETCORE_TOKEN`) by the module. The pairing token is also set into a header (`MS-ASPNETCORE-TOKEN`) on every proxied request. IIS Middleware checks each request it receives to confirm that the pairing token header value matches the environment variable value. If the token values are mismatched, the request is logged and rejected. The pairing token environment variable and the traffic between the module and Kestrel aren't accessible from a location off of the server. Without knowing the pairing token value, a cyberattacker can't submit requests that bypass the check in the IIS Middleware.

Changing this so it is technically correct. It lost some clarity. Requests are the subject being guaranteed about.

[wadepickett]

Suggested change

	The <xref:System.Configuration.SectionInformation.InheritInChildApplications*> property is set to `false` to indicate that apps that reside in a subdirectory of the app aren't inheriting the settings specified within the [\<location>](/iis/manage/managing-your-configuration-settings/understanding-iis-configuration-delegation#the-concept-of-location) element.
	The <xref:System.Configuration.SectionInformation.InheritInChildApplications*> property is set to `false` to indicate that apps that reside in a subdirectory of the app don't inherit the settings specified within the [\<location>](/iis/manage/managing-your-configuration-settings/understanding-iis-configuration-delegation#the-concept-of-location) element.

Changing to match line 193 improvment you had which was better.

[wadepickett]

Suggested change

Because ASP.NET Core apps run in a process separate from the IIS worker process, the module also handles process management. The module starts the process for the ASP.NET Core app when the first request arrives and restarts the app if it crashes. This is essentially the same behavior as seen with ASP.NET 4.x apps that run in-process in IIS that the [Windows Process Activation Service (WAS)](/iis/manage/provisioning-and-managing-iis/features-of-the-windows-process-activation-service-was) manages.

Because ASP.NET Core apps run in a process separate from the IIS worker process, the module also handles process management. The module starts the process for the ASP.NET Core app when the first request arrives and restarts the app if it crashes. This is essentially the same behavior as seen with ASP.NET 4.x apps that run in-process in IIS that are managed by the [Windows Process Activation Service (WAS)](/iis/manage/provisioning-and-managing-iis/features-of-the-windows-process-activation-service-was).

Minor item: The trailing clause seemed a little awkward.

[wadepickett]

Suggested change

	When disabling the Web SDK from transforming the file, the developer should mannually set the `processPath` and `arguments`. For more information, see <xref:host-and-deploy/aspnet-core-module>.
	When disabling the Web SDK from transforming the file, the developer should manually set the `processPath` and `arguments`. For more information, see <xref:host-and-deploy/aspnet-core-module>.

Minor: typo.

[wadepickett]

Suggested change

	| [`X-Forwarded-Proto`](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/X-Forwarded-Proto) (XFP) | The value of the originating scheme, HTTP, or HTTPS. The value might also be a list of schemes if the request has traversed multiple proxies. |
	| [`X-Forwarded-Proto`](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/X-Forwarded-Proto) (XFP) | The value of the originating scheme, HTTP or HTTPS. The value might also be a list of schemes if the request has traversed multiple proxies. |

Very minor: Reads a bit odd with the extra comma, so removed it.

[wadepickett]

@lootle1, great work! I made some suggestions, which you can commit if you want to use them as-is. There were only two medium issues a couple very minor ones.