2

I'm getting below error in 10 % of my requests on production env.

I've tried also from local and many different browsers and devices (BrowserStack) and I still didn't succeed to reproduce an issue.

"errors": [
        {
          "status": "405",
          "title": "Method Not Allowed",
          "detail": "HTTP method is not allowed"
       }
]

Error that is caught from browser console (Angular)

"error": "[ProgressEvent]",
"headers": "[ti]",
"message": "Http failure response for https://api.xxxxxx:5000/api/public-web/files: 0 Unknown Error",
"name": "HttpErrorResponse",
"ok": false,
"status": 0,
"statusText": "Unknown Error",
"url": "https://api.xxxxxx:5000/api/public-web/files"

POST https://api.xxxxxxx:5000/api/public-web/files/upload

Logs are from Sentry

Stack:

  • .Net Core 6
  • Angular 15 - Universal
  • Server: Windows 2019 → IIS 10

1 ) I've covered CORS just on the IIS with above custom headers in web.config, not on the application side. - DONE
2) I’ve already tried to remove WEBDAV module - DONE
3) Also from IIS side I’ve turned on failed request tracing and logs, and on both sides of logs that request doesn’t even appears. - DONE

Firstly, I was thinking an issue is related to the CORS but although that I had already configured CORS on backend side, I've also added following to all response headers on the server in web-config (IIS) as can be seen down bellow from full web.config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <location path="." inheritInChildApplications="false">
        <system.webServer>
            <modules>
                <remove name="WebDAVModule"/>
            </modules>
            <httpProtocol>
                <customHeaders>
                    <clear/>
                    <add name="Access-Control-Allow-Origin" value="*"/>
                    <add name="Access-Control-Allow-Methods" value="GET,POST,PATCH,PUT,DELETE,OPTIONS"/>
                    <add name="Access-Control-Allow-Headers" value="*"/>
                </customHeaders>
            </httpProtocol>
            <handlers>
                <remove name="WebDAV"/>
                <add name="aspNetCore" path="*" verb="GET,POST,PATCH,PUT,DELETE" modules="AspNetCoreModuleV2" resourceType="Unspecified" requireAccess="None"/>
            </handlers>
            <aspNetCore processPath="dotnet" arguments=".\xxxx.Api.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess"/>
        </system.webServer>
    </location>
    <system.webServer>
        <tracing>
            <traceFailedRequests>
                <add path="*">
                    <traceAreas>
                        <add provider="ASP" verbosity="Verbose"/>
                        <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose"/>
                        <add provider="ISAPI Extension" verbosity="Verbose"/>
                        <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module,FastCGI,WebSocket,ANCM,Rewrite,Cors,iisnode" verbosity="Verbose"/>
                    </traceAreas>
                    <failureDefinitions statusCodes="400-999"/>
                </add>
            </traceFailedRequests>
        </tracing>
    </system.webServer>
</configuration>

Route on the .Net Core:

[HttpPost("upload")]
[DisableRequestSizeLimit]
public async Task<IActionResult> Upload(IFormFile file, CancellationToken cancellationToken) {
    var fileDto = await _fileService.UploadApplicationDocument(file, cancellationToken);
    return ResponseObjectStatusCode(new ResponseObject<object>(fileDto));
 }

It seems like HTTP Request doesn't reach the server at all…

mmiroslav13
  • 21
  • 2
  • Depending on how reliable you can reproduce the errors, FRT can tell you what exactly happens, https://learn.microsoft.com/en-us/iis/troubleshoot/using-failed-request-tracing/troubleshoot-with-failed-request-tracing Note that 1) IIS is so flexible that anything can give you 405, and reading posts from others without first matching with your environment can be misleading. 2) Use IIS CORS module, not your own `customHeaders` so that you can fine tune the settings and avoid common flaws. – Lex Li Dec 15 '22 at 16:59
  • @LexLi 1) FRT is telling me nothing, as I said from server side I don't even see that request. Neither in server logs & frt but also I can't see those bad requests in file logs of my serilog (app side). All I can see it's from Sentry (Angular side). 2) Firstly I've tried IIS CORS module but the same issue was happenning, then I switched to customHeaders but still the same. I've also updated post with full web.config. – mmiroslav13 Dec 16 '22 at 09:33
  • You will have to share more than that, as this config file only contains your ASP.NET Core settings. How did you configure your Angular Universal app on IIS for server side rendering? – Lex Li Dec 17 '22 at 03:45
  • @LexLi I’ve followed this article with the same web.config https://www.thecodehubs.com/how-to-deploy-ssr-angular-universal-to-iis/. .Net core and Angular are 2 separates apps on IIS and on Angular side I have also one more rewrite rule for http to https. – mmiroslav13 Dec 21 '22 at 10:18
  • Use developer tools to check whether there is information about this request in the Network. – samwu Dec 23 '22 at 06:25
  • what does the route look like in the server? – d0rf47 Jan 11 '23 at 21:16
  • @d0rf47 I've update the post. Pretty much simple and straightforward, but request doesn't even reach this route in those 10%.. – mmiroslav13 Jan 11 '23 at 21:22
  • You posted an error that shows `"message": "Http failure response for https://api.xxxxxx:5000/api/public-web/files: 0 Unknown Error"` but also a POST request at `https://api.xxxxxxx:5000/api/public-web/files/upload` Those paths are not the same. Which is correct? If you remove IIS entirely and just point at kestrel does it work? – Simon Jan 12 '23 at 09:13
  • @Simon You're right, my mistake. I've update the post. I didn't tried to remove an app from IIS and run it on kestrel. I can try it.. Do you think it will work differently on kestrel? – mmiroslav13 Jan 12 '23 at 13:33
  • It removes a lot of complexity and will tell you whether your problem exists in IIS configuration. If it works without IIS, you know IIS config is the problem. If it still fails, then you know that IIS isn't the problem. You may also be able to see clearly logs without IIS in the middle – Simon Jan 13 '23 at 14:03

0 Answers0