A Uniform Resource Identifier (URI) identifies a resource. In an ASP.NET Core application, the most familiar address is a URL: a web address with a hostname and a path to a resource. Entering a URL in a browser sends an HTTP request to the server associated with that hostname; the server returns a response the browser can display. section 31.1.4 section 1.4.1
URLs matter in several practical places:
- Listening: Outside IIS reverse-proxy hosting, an app may need an explicit listening URL. ASP.NET Core defaults to http://localhost:5000; ASPNETCORE_URLS or the --urls command-line argument can change it. section 27.4
- Redirecting: A login page may receive a returnUrl so users can resume where they left off. Check a user-provided return URL with Url.IsLocalUrl() before redirecting, or use LocalRedirect(), which rejects nonlocal URLs. Some OpenID Connect flows instead require preregistered redirect URLs. section 29.4.1
- Handling a fixed path: Custom middleware can respond to a well-known URI such as /.well-known/security.txt without depending on the app’s routing configuration. section 31.1.4
Listing 31.8 A Security.txt handler implemented as middleware
public class SecurityTxtHandler
{
private readonly RequestDelegate _next;
public SecurityTxtHandler(RequestDelegate next)
{
_next = next;
}
public Task Invoke(HttpContext context)
{
var path = context.Request.Path;
if(path.StartsWithSegments("/.well-known/security.txt")) #1
{
context.Response.ContentType = "text/plain"; #2
return context.Response.WriteAsync( #2
"Contact: mailto:security@example.com"); #2
}
return _next.Invoke(context); #3
}
}
This C# middleware checks the request path, writes a plain-text response for the well-known URI, and passes other requests to the next component. section 31.1.4
