为什么我在 Asp.Net Core 日志中收到“不支持 POST 请求”？

Question

I have an ASP.NET Core 5 API setup. I also have a few Razor pages that use static content. I am using JWT for authentication. In my UserController I have an action stub where I am developing a change password action:

    [Authorize]
    [HttpPost("ChangePassword")]
    public IActionResult ChangePassword([FromBody] string password)
    {
        HttpContext.Items.TryGetValue("User", out var user);

        _logger.ForContext<UsersController>().Debug("User {EmailAddress} tried to change his password to {Password}.", ((User)user).EmailAddress, password);

        return Ok();
    }

This works and logs as tested with Swagger. I have other POST actions. This is the first time I try to get the user with HttpContext .

However, only with this new Action, I get in my log two entries:

23 Jul 2021 21:36:24.612 POST requests are not supported
23 Jul 2021 21:36:24.605 POST requests are not supported

The log (Seq) shows the SourceContext is Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware .

I am wonder why I am getting these two log entries and can I safely ignore them?

Answer 1

That log entry is coming from StaticFileMiddleware checking if it should take over the request and return a file response.

public class StaticFileMiddleware
{
    // ...
    public Task Invoke(HttpContext context)
    {
        if (!ValidateNoEndpoint(context))
        {
            _logger.EndpointMatched();
        }
        else if (!ValidateMethod(context))
        {
            // 👇 "POST requests are not supported"
            _logger.RequestMethodNotSupported(context.Request.Method);
        }
        else if (!ValidatePath(context, _matchUrl, out var subPath))
        {
            _logger.PathMismatch(subPath);
        }
        else if (!LookupContentType(_contentTypeProvider, _options, subPath, out var contentType))
        {
            _logger.FileTypeNotSupported(subPath);
        }
        else
        {
            // If we get here, we can try to serve the file
            return TryServeStaticFile(context, contentType, subPath);
        }

        return _next(context);
    }
}

Since it doesn't serve a static file, it calls the next middleware in the chain, which eventually lets the request be dispatched to your controller.

You can safely ignore it. It's logged at Debug level and only matters if you're having problems with static files.