Production engineering
Reveal answer and reasoning
The HTTP Host field can influence routing and generated links, but it is still caller-controlled request data until an application enforces its chosen policy. This lesson separates acceptance of a known host from construction of a trusted public link. The real fixture restricts incoming hosts to lab.example for this scenario, while /canonical builds its example URL from a fixed application-owned base.
Neither rule authenticates a tenant or establishes DNS ownership. The local TCP connection remains directed at127.0.0.1, and the fictional public URI is returned as data rather than requested. That separation makes the two policies independently testable.
The lesson20 archive supplies AllowedHosts=lab.example in appsettings.json. Program.cs registers Host Filtering Middleware from the configured allowlist and places it in the request pipeline. Requests still connect to the loopback address, but the test explicitly supplies the Host field. An allowed host reaches /canonical; an unrecognized host is rejected with400. The endpoint exposes the observed host separately from the fixed generated URL.
Reading those two fields together proves that the link is not simply reflected from the incoming host. Other lesson archives use a wildcard host setting, so preserve this lesson's supplied configuration when reproducing its expected behavior.
What a strong answer covers
- The HTTP Host field can influence routing and generated links, but it is still caller-controlled request data until an application enforces its chosen policy.
- The lesson20 archive supplies AllowedHosts=lab.example in appsettings.json.
- Kestrel binding to an address and validating the Host field answer different questions.
Common pitfall
Kestrel binding to an address and validating the Host field answer different questions. A working loopback connection does not make an arbitrary Host trusted, and a host allowlist is not a permission check for a person or tenant. Reverse-proxy configurations may preserve or replace host metadata, requiring a policy appropriate to that path. This fixture does not enable forwarded-host rewriting or install TLS certificates for the fictional domains. It also has no authenticated tenant resolver. Keep those absent responsibilities visible instead of presenting a canonical HTTPS string as evidence that a public service or trusted tenancy boundary was deployed.
Follow-up questions
- How could importing another lesson’s wildcard AllowedHosts file invalidate the host-filter test without changing its endpoint code?
- What separate evidence would be needed to establish TLS or tenant permission for the fictional canonical URI?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.