There are lots of jokes about HTTP status codes, what they mean, and general frustration with the inconsistent way in which they're used.

HTTP 1xx

• 100: Continue sending me the request.

HTTP 2xx

• 200: OK, here you go.
• 201: OK, I created it for you.

HTTP 3xx

• 301: Moved what you want to a new spot over here.
• 302: Found what you're looking for over here.

HTTP 4xx

• 400: Your bad.
• 401: You aren't logged in.
• 403: You're logged in, but can't do/see that.

HTTP 5xx: Our bad

• 500: We screwed up.
• 503: We forgot to start the server.

There are many more status codes, and as a developer I ecourage other developers to use appropriate and specific response codes. For more specific details, Wikipedia has a good overview.

With a route like /change/{id} the ID parameter is implicitly implied if the view contains a form with method="post" back to the same action name, for example:

View:

<asp-form asp-action="change" method="post">

Controller:

[HttpPost]
public ActionResult Change(int id, Model model)

When changing the form action to to include a change confirmation step:

<asp-form asp-action="confirmChange" method="post">

The id route parameter was not included by default anymore, so the controller action was receiving a default(int):

[HttpPost]
public ActionResult ConfirmChange(int id, Model model)

ASP.NET Core seems to include the current route parameters when posting back to the same action name.

The fix was fairly simple, you must explicitly include the route parameters on the <asp-form> tag when posting across action names.

<asp-form asp-action="change" asp-route-id="@Model.SomeId" method="post">

See also: Stack Overflow on updating route parameters.

While attempting to setup SSH access to a Windows 10 machine, following this guide: https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse, I kept running into a generic Windows install failed error. It became apparent that the issue was because the system was failing to download the optional windows feature.

Turns out that for some reason the WSUS server that the machine was connected to didn't have that optional feature, so a local gpedit was necessary to configure the machine to directly download optional features from Windows Update.

After checking the box here, it was as simple as re-running the install from the Settings app.