Azure app service some requests returns 400 Bad Request. The request could not be understood by the server due to malformed syntax - azure-web-app-service

So we have a simple .net core 5.0 service that only serves some simple pages with mvc. We are starting to get 400 Errors (details below) on some of the requests. Our frontend is embedded in an iframe which forces us to use our own domain for our api-calls. The 400 errors disappears when we use the azure internal-urls. (*.azurewebsites.net instead of *.ourdomain.net). When I get to the "diagnose and solve problems" -> "availability and performance" -> HTTP 4XX ERRORS i can se below errors. Any ideas on what can cause this error?
Bad Request. The request could not be understood by the server due to malformed syntax. The client should not repeat the request without modifications.

So, the biggest problem above is that we do not get the correct errormessage. After a lot of experimentation we activated the ConnectionLogging for Kestrel.
WebHost.CreateDefaultBuilder(args)
.UseKestrel(options =>
{
options.ConfigureEndpointDefaults(listenOptions =>
{
listenOptions.UseConnectionLogging();
});
})
And after that we found some more intressting logs. One that said:
Connection id "0HMFSA73IA4LS" bad request data: "Malformed request: invalid headers."
Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Malformed request: invalid headers.
After some more investigation we could diff a succesful request from a failing request. And the problem was related to the certificate of *.ourdomain.se. In a part of the certificate we hade a string thats named "Stockholms län" in the cases where it failed the string decoded to l�n and when it succeeded the string decoded to l%C3%A4n. We are now investigating if this is a load balancer problem. But this app is running hostingmodel outofprocess. By changing this to inprocess and wrap our Kestrel in IIS the errors disapears.

Related

LoadRunner replay error : Action.c(312): Error -26630: HTTP Status-Code=401 (Unauthorized)

I have co-related all the required dynamic values, added cookies & headers in the recorded load test script. But, I can't able to get a successful login into the application.
It throws an error Action.c(312): Error -26630: HTTP Status-Code=401 (Unauthorized) in the login transaction itself.
Action.c(312): Error -26630: HTTP Status-Code=401 (Unauthorized) for "https://myapplicationURL" [MsgId: MERR-26630]
Is there any other missing values need to be added in the script, Please let me know.
Thanks in advance.
Seems that you haven't correlated the the dynamic values. Or the credentials that you are using are not valid.
You can debug this problem by looking into the snapshots of your previous requests.

Docusign: HTTPS required for Connect listener communication error

I'm trying to use the Docusign API for an application that I'm running locally and I see the following error:
"message":"Uncaught Error when executing a Single
Cause: com.docusign.esign.client.ApiException: Error while
requesting server, received a non successful HTTP code 400 with response Body:
'{"errorCode":"HTTPS_REQUIRED_FOR_CONNECT_LISTENER",
"message":"HTTPS required for Connect listener communication."}'
Description: com.docusign.esign.client.ApiException: Error while
requesting server, received a non successful HTTP code 400 with response Body:
'{"errorCode":"HTTPS_REQUIRED_FOR_CONNECT_LISTENER",
"message":"HTTPS required for Connect listener communication."}
I am behind a company proxy but I have been able to use the API in the past and create envelopes without an issue so I'm not sure how to address this. Any help would be greatly appreciated.
This change is discussed in the Jan release notes.
Connect can only be used with https listeners (customers' servers).
And note that the server must use a certificate that chains to a root cert in the Microsoft standard root cert list. (Self-signed certs won't work.) You can use a free cert from LetsEncrypt or a $15 cert from a reputable CA.
I'm sorry that this update caught you by surprise.
Getting error now, it was working fine before:
Fatal error: Uncaught DocuSign\eSign\Client\ApiException: Error while requesting server, received a non successful HTTP code [400] with response Body: O:8:"stdClass":2:{s:9:"errorCode";s:35:"HTTPS_REQUIRED_FOR_CONNECT_LISTENER";s:7:"message";s:50:"HTTPS required for Connect listener communication.";}

Getting HTTP error 400- Header too long error

I am getting HTTP 400- Header too long error, I have tried most of solution over internet, but none of them seemed to be working (solutions are like adding reg entries, etc).
I have a sample web application which is calling a web api on my system, but I am getting below error in HTTPERR log file:
2019-11-16 16:58:59 ::1%0 1213 ::1%0 80 HTTP/1.1 GET
/WebApplication2/api/values - 400 - RequestLength -
Here is my code which is calling the web API:
HttpWebRequest GETRequest = (HttpWebRequest)WebRequest.Create(URL);
GETRequest.Method = "GET";
GETRequest.ContentType = "application/json";
GETRequest.Headers.Add("Authorization", "<Something Big value>");
WebResponse GETResponse = await GETRequest.GetResponseAsync();
It is recommended to capture ETL log via
https://blogs.msdn.microsoft.com/wndp/2007/01/18/event-tracing-in-http-sys-part-1-capturing-a-trace/
Then you could use network monitor to analyze both request payload and etl log.
It will help you find the root cause.
Besides, can you find the 400 error in IIS log? Now that the 400 error appear in httperr log. It looks like http.sys blocked the request before it reach IIS server.
If you can find the 400 error in IIS , then you could try to modify the limitation in system.web/httpRuntime and request filter.
If the 400 error only can be found in httperr log. Then you may have to try to make some change in http.sys registry.
https://support.microsoft.com/en-us/help/820129/http-sys-registry-settings-for-windows
Please remember to reboot server to activate these registry!

Application Insights Availability tests fails on 200 OK with "System.UriFormatException: Invalid URI: The format of the URI could not be determined."

I am just trying out Application Insights availability tests.
I let them run over night to our public website and got only "fails"
When I drill in to the separate test runs, I see that the server responded with "200 OK", sending the expected html markup.
But in "Exceptins" it says
System.UriFormatException: Invalid URI: The format of the URI could not be determined.System.UriFormatException: Invalid URI: The format of the URI could not be determined.
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at Microsoft.VisualStudio.TestTools.WebTesting.HtmlDocument.ParseForDependentRequests(Boolean urlsOnly)
at Microsoft.VisualStudio.TestTools.WebStress.WebTestCaseVariation.BuildDependentRequestsList(WebTestInstrumentedTransaction instrumentedTransaction)
at Microsoft.VisualStudio.TestTools.WebStress.WebTestCaseVariation.AddParsedDependentRequests(ExecutionState executionState)
Does anyone have an idea what's going on there? What am I missing?
Most likely this exception occurs when webtest engine tries to parse dependent requests information to validate resources. Either webtest incorrectly parses dependency resource or web page contains an invalid reference.
WebTest should give a better error explaining to which resource it is complaining.
To workaround this problem (if it is acceptable) - you can disable "Parse dependent requests" option (see below). Note - webtest will not be testing dependent resources.

ParseError in Yesod.Core.Class.Yesod

I have a Yesod web application, that calls a web service on another server. I reuse the Http Manager from yesod for my Requests to that web service.
On some calls, I'm getting a Yesod error, and I'm not sure why the Yesod error handler is kicking in, since the error handling is not part of the Manager.
My code does its own status handling on the HTTP response (I do let req' = req { H.checkStatus = \_ _ _ -> Nothing } on the request).
The error I'm getting:
07/Jun/2013:14:05:15 +0200 [Error#yesod-core] ParseError {errorContexts = [], errorMessage = "Failed reading: satisfy", errorPosition = 1:1} #(yesod-core-1.2.0.4:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:471:5)
I have the distinct impression that the web service returns an error, and Yesod is handling it instead of my code. My web service client code throws exception that are caught to be redirected to an error page, and this works well when I do errors in the invocation of the service, I just don't understand why I'm getting this ParseError on some requests.
I'm dumping the request and the response that I get from the web service, and I never see the response in my log, which seems to indicate that yesod is intercepting the response.
Any idea?
OK, sorry for the stupid question, I've figured it out. The http-conduit code is throwing the ParseError, and my code was not catching it, so Yesod was barfing. If I catch the ParseError, I get my error page. Now, is it normal that http-conduit fails with such an abrupt message, I don't know, but I do think the web service is misbehaving anyway.

Resources