FOREWORD
This may well be the weirdest problem I have ever witnessed in 15 years. It is 100% reproducible on a specific machine that sends a specific request when authenticated as a specific user, if the request is sent from Chrome (it doesn't happen from Edge, it doesn't happen from cURL or Postman). I can't expect an exact solution to my disturbingly specific issue, but any pointers about what could theoretically cause it are more than welcome.
WHAT HAPPENS
We have several PCs in our factory, that communicate with a central HTTP server (hosted on premise, if that even matters: they're on the same LAN). Of course, we have users who could work on any of these machines.
When a certain user does a specific action on a certain one of those machines, she gets a message about an "HTTP error". The server responds with a 400, specifying that the JSON in the request is ill-formed. Fine, let's look at the JSON: it's an 80-characters string, and it looks very well-formed. I check its length, and it is in fact an 80-character string, and the request has a Content-Length of 80. All is fine, but the server responds with the 400.
The same user on a different machine, or a different user on the same machine, or any other user on any other machine can do the very same action and the very same corresponding HTTP request. The same user, on that machine, can do the action fine using Edge instead of Chrome (despite both being Chromium-based). If I "export" the request from the browser's Dev Tools into any format (cURL bash, cURL cmd, JS fetch...), the request in Chrome and the one in Edge look the same.
Our UI sends the request using Axios. If I send it with fetch, I still get the error. If I serialize the JSON myself and send the string (instead of letting Axios/fetch handle the serialization), I still get the error. If I send that same request using any other client (cURL from command line, Postman...) I don't get the error - same as in Edge.
WHAT I FINALLY NOTICED (and how I hacked the issue into submission)
The server is ASP.NET Core (using .Net 5), so I added a middleware to record the received request. Apparently, in the specified conditions, the server receives a request body that is different from what was sent by the client. Say the client sends:
{"key1":"value1","key2":"value2"}
Well, the server receives:
{"key1":"value1","key2":"value2"
Notice the newline at the beginning and the missing closing brace at the end. The body apparently gets an extra character at the start, and the final character is lost - either because it is not actually sent/received or because the Content-Length dictated it to be truncated.
This clearly explains the failed deserialization (the string is in fact invalid JSON) and the resulting 400 response.
Since this bug had been blocking or hindering production for several days, I wrote a "healer" middleware, that tries to deserialize the JSON string received (if the Content Type indicates JSON, of course); if it fails, it looks for a single non-opening-brace character at the start of the string, and if it finds it it rewrites the body by removing that character and appending a closing brace. It lets the healed request go down the pipeline and notifies me via e-mail.
THE AFTERMATH
All has been working fine since I released the fix, and we even asked or system managers to replace the PC that was causing problems, since we could only think of a vicious issue with OS/browser setup or configuration that caused conflicts.
However, when they replaced it, I started getting the notification e-mail again... this time from other two users, always on that same machine, each of them having the same issue (that is being healed, btw), each of them on a different request (but always the same request for each user). The requests point to different URLs and their bodies have different lengths and complexity (JSON-wise). I haven't tried all the tests I did before (different browser, cURL, fetch...) but the diagnosis of the problem is the same, and it is being handled by the healer middleware.
A colleague reported that they already had a similar problem several months ago, which they didn't investigate back then. They're not sure it was the very same workstation, but they replaced the PC and the error didn't happen any more. It seems to be pretty much random, and I still have no idea what could cause such a behaviour.
Here is some more info about the platform, if any of this is relevant:
clients: Windows 10 PCs, using Chrome in kiosk mode, launched by a batch that is located on a network share;
UI: React, sending HTTP requests with Axios;
server: .Net 5 ASP.NET Core service.
UPDATE
I've recorded the network traffic using Wireshark on the client PC. Here is what I got:
So apparently the request is already modified when it leaves the client host.
An asmx service we're hosting under IIS decided to attach below message at the top of xml response body rendering the xml invalid. The guid is unique in each response.
Your request could not be processed. Please press the back button on
your browser and try again. If the problem persists, please contact
technical support. Information below is for technical support:
Support Code: 7d6cbea0-9491-4cb0-9ca0-32f0a8b41bc4
I've limited access to the source; it does not appear like this is coming from the application code itself. Googling brings several hits current or cached having exactly the same behavior (variation of "could not processed" or "could not be processed" in different cases):
https://www.histiocure.org/jTlSn/about.aspx
https://webcache.googleusercontent.com/search?q=cache:8gRsTgrCarQJ:https://retirement.insperity.com/education.aspx+&cd=4&hl=en&ct=clnk&gl=us
https://www.perfectprovisions.org/index.aspx
Yet, I don't get any hit from technical sites like stackoverflow or MSDN. This is very puzzling; has anyone seen this behavior? Is it IIS doing this? What causes this?
BTW, the issue itself was resolved when AppPool was restarting but I'm worried that this can happen again anytime unless we get to the bottom of this.
I am working on a relatively complex asp.net web forms application, which loads user controls dynamically within update panels. I've run into a very peculiar problem with Internet Explorer where after leaving the page idle for exactly one minute you receive a Sys.WebForms.PageRequestManagerParserErrorException javascript exception when the next request is made. This doesn't happen in Firefox and Chrome. When the server receives the bad request, the body is actually empty but the headers are still there. The response that is sent back is a fresh response you would get from a GET request, which is not what the update panel script is expecting. Any requests done within a minute are okay. Also any requests made following the bad request are okay as well.
I do not have any response writes or redirects being executed. I've also tried setting ValidateRequest and EnableEventValidation in the page directive. I've looked into various timeout properties.
The problem resided with how IE handles NTLM authentication protocol. An optimization in IE that is not present in Chrome and Firefox strips the request body, which therefore creates an unexpected response for my update panels. To solve this issue you must either allow anonymous requests in IIS when using NTLM or ensure Kerberos is used instead. The KB article explains the issue and how to deal with it.KB251404
I was trying to track down why my site was so painfully slow in IE9 when I pulled out Fiddler and realised that every request is being sent 3 times (twice I get 401.2 and then a success). I verified this happens on all browsers, its just that Chrome's speed was masking this (or it could be that this has nothing to do with my sites performance issues in IE).
I've set up break points in my begin/end request handlers and the request comes in for say a css file. It is not authenticated and the response goes out with a 401.2, I doubled checked that I'm not setting the response status anywhere myself, so somewhere between begin_request and end_request the status is changing to 401.2
Note: I have the runAllManagedModulesForAllRequests=true so I can configure compression, however this setting does not affect this (from what I can see from Fiddler).
I am very ignorant on kerberos/active directory in general but I just cannot fathom that this is a normal handshaking protocol for every single request (perhaps for the first? but not all).
I have scoured the googles and nothing seems to help (adding/removing modules/authentication providers, etc). I mean my site works just fine, its only once you look under the hood that I see the treplicated requests. Note: This also happens when I deploy to production so its not a server specific issue.
Has anyone ever seen this? thanks in advance.
I think this is how NTLM authentication works. The process is discussed here. Note that you will want to set AuthPersistSingleRequest to false to cut down on the number of 401s
What does "Pending" mean under the status column in the "Network" tab of Google Chrome Developer window?
This happens when my page script issues a GET request whose response contains content-headers for downloading a CSV file:
Content-type: text/csv;
Content-Disposition: attachment; filename=myfile.csv
This works fine in FF and IE7, downloading a CSV file as expected and opening a file picker to save the file, but Chrome does nothing. I confirmed that the server responds to the request, so it appears that Chrome will not process the response.
Curiously, all works as expected if I type the URL into Chromes address bar and hit <enter>.
FYI: Chrome 10.0.648.204 on Windows XP
In my case, I found that the "pending" status was caused by the AdBlock extension. The image that I couldn't get to load had the word "ad" in the URL, so AdBlock kept it from loading.
Disabling AdBlock fixes this issue.
Renaming the file so that it doesn't contain "ad" in the URL also fixes it, and is obviously a better solution. Unless it's an advertisement, in which case you should leave it like that.
I also get this when using the HTTPS everywhere plugin.
This plugin has a list of sites that also have https instead of http. So I assume before the actual request is made it is already being cancelled somehow.
So for example when I go to http://stackexchange.com, in Developer I first see a request with status (terminated). This request has some headers, but only the GET, User-Agent, and Accept. No response as well.
Then there is request to https://stackexchange.com with full headers etc.
So I assume it is used for requests that aren't sent.
I had some problems with pending request for mp3 files.
I had a list of mp3 files and one player to play them. If I picked a file that had already been downloaded, Chrome would block the request and show "pending request" in the network tab of the developer tools.
All versions of Chrome seem to be affected.
Here is a solution I found:
player[0].setAttribute('src','video.webm?dummy=' + Date.now());
You just add a dummy query string to the end of each url. This forces Chrome to download the file again.
Another example with popcorn player (using jquery) :
url = $(this).find('.url_song').attr('url');
pop = Popcorn.smart( "#player_", url + '?i=' + Date.now());
This works for me. In fact, the resource is not stored in the cache system. This should also work in the same way for .csv files.
I had the same issue on OSX Mavericks, it turned out that Sophos anti-virus was blocking certain requests, once I uninstalled it the issue went away.
If you think that it might be caused by an extension one easy way to try and test this is to open chrome with the '--disable-extensions flag to see if it fixes the problem. If that doesn't fix it consider looking beyond the browser to see if any other application might be causing the problem, specifically security apps which can affect requests.
I had a similar issue with application/json ajax calls. In ff/IE they were fine. In chrome in the Developer Network window Status was always (pending) because a different status code was being returned.
In my case I changed my Json response to send a HttpStatusCode of 200 then Chrome was fine and the Status Text changed to 200 OK.
For example using ASP.NET Web Api
return new HttpResponseMessage(HttpStatusCode.OK ) {
Content = request.Content
};
The Network pending state on time, means your request is in progressing state. As soon as it responds the time will be updated with total elapsed time.
This picture shows the network call is in processing state(Pending)
This picture shows the time taken in processing by network call.
The fix, for me, was to add the following to the top of the php file which was being requested.
header("Cache-Control: no-cache,no-store");
Same problem with Chrome : I had in my html page the following code :
<body>
...
<script src="http://myserver/lib/load.js"></script>
...
</body>
But the load.js was always in status pending when looking in the Network pannel.
I found a workaround using asynchronous load of load.js:
<body>
...
<script>
setTimeout(function(){
var head, script;
head = document.getElementsByTagName("head")[0];
script = document.createElement("script");
script.src = "http://myserver/lib/load.js";
head.appendChild(script);
}, 1);
</script>
...
</body>
Now its working fine.
Encountered a similar issue recently.
My App is in angular 11 and we have a form with some validators which have regex to validate the data. One of data element had a special character which the regex wasn't handling and it made the entire browser hung up. Infact, even though all network calls were successful with 200 Ok, chrome was not showing any response returned by the backend and was also showing the requests in Pending State when infact all network calls are successful, there was no console log errors or anything. Handling the regex fixed the issue.
After i found the issue, i googled more about it. Here is more explanation about it.
https://javascript.info/regexp-catastrophic-backtracking
I came across this issue when I was debugging a local web application. The issue turned out to be AVG Antivirus and Firewall restrictions. I had to allow an exception through the firewall to get rid of the "Pending" status.
In my case, a simple restart to my browser (chrome) and it worked straight away afterwards like magic!
Little bit of context, I happen to refresh my frontend web page and straight away went onto making a changes to my API which led it to restart. During that instance, the frontend was making calls to API which led into "pending" due to that API is reloading. Browser at this point cached that pending state. For me to get out of it is either I set no-cache (which I didn't want to) or simply restart the browser, I chose the restart.
A little background
I encountered such an issue when requesting an url in my Django project. The server is setup using Apache HTTP web server and basic auth for user authentication.
The url I was accessing required no authentication to access i.e. in my Apache config, I had set Require all granted on the url using the LocationMatch directive.
The issue
The url I was trying to access returned 200 status (in the Network tab in Chrome), but the static assets being used for styling of the requested webpage (css, javascript, font files etc.) associated with the request url were not loading and returned pending status.
In the meanwhile, the page loaded partially and still kept on loading. All this was happening in the presence of basic-auth dialog in browser, even though my url was granted all access.
What worked for me
Interestingly, as I entered my credentials and logged in, the requested page loaded all the static assets. This made it very clear to me that the static assets directory might NOT have the necessary access permissions.
Then, I granted the access to the static assets directory by updating my Apache config and then the requested url and the webpage loaded up fine (200 status) without any basic auth dialog OR pending status.
In my case, there's an update for Chrome that makes it won't load before you restart the browser. Cheers
I encountered the same problem when I request certain images from page. I use JavaScript to set the src attribute of an img object and if the network is poor pending will be displayed in the network panel of chrome developer window. I think it's due to the poor network.