There is some very strange behavior of the same request on Chrome and Firefox.
I have one button that triggers POST request to a Spring-boot backend, it's kind of long-running, takes ~5-6min.
On Chrome, there are no issues and every time I get the expected response for the above-mentioned time(5-6min), and only 1 request is received by the backend.
On Firefox on the other hand I make the same POST request through that button and the strange thing is that the request stays blocked for 6mins and after that is somehow retriggered. This happens 9 out of 10 times.
This results in 2 requests made to the backend from a single request in the frontend.. at least this is what it looks like from the logs that I put in the backend.
The second request starts exactly after the block time.
There aren`t any other XHR requests being executed at the same time.
Below is a screenshot of how it looks:
Does anyone have any idea what might cause this behaviour on Firefox?
Related
I've an issue requesting some data in JS and i get status code 503 and also a message that i don't know what it means,it seems like the memory located to the request is not enought and i would like to know why and how to solve, here the screenshot:
You can manually see it on chrome's dev tools (network section) on this page: PAGE
You can also notice that if you refresh the page more times the requests that fails are everytime different.
I won't write all the code here because is too long, but i leave the link, i'm sorry but this is not my own script and it is compressed.
this is the file that triggers the error.
CODE
THIS IS THE ERROR FROM CPANEL:
couldn't create child process: /usr/sbin/suphp for /home/smmmainp/public_html/index.php, referer: https://smm-mainpanel.com/services
I looked up your site and your server is returning an Exceeded Resource Limit Error Show Image.
"The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later".
It is not a JavaScript problem, it is an HTTP Request problem, server-side. The "jQuery" that's showing in your Console is probably the Request Initiator, and when some problem happens with your Request, the jQuery needs to Handle it and send an error message. But stills a Server-Side error.
You need to look into your cPanel, go to "Stats" page and look your HTTP Request Limit, in order to know how much requests daily (or per hour) your server handle. Review your Server Provider Plan and contact them.
Best regards!
I experienced very weird bug during using fetch API. As the picture above shows, the method property of Request is POST, but fetch send the request using GET method.
Also, among three macbooks, two macbooks(one Catalina beta, one Mojave) experienced the same bug, but one macbook(Mojave) did not. The last one just works perfectly.
All three machines used same Wifi network and same version of Chrome.
Where can I start to solve this bug? Any kind of suggestion will be very helpful. Thanks!
Look at the log message closely, it says:
redirected: true
So you are making a POST request, but the server responds with a redirect response so the browser follows the redirect and makes a GET request to the new URL. This is handled transparently by the fetch API.
I think you have to check your two urls, it is different
not same url
I am familiar with http status codes, but recently I saw a strange line in my chrome debugger. Instead of ordinary Status Code:200 OK I saw the following: Status Code:200 OK (from ServiceWorker).
My guess is that this just tells me that ServiceWorker is somehow responsible for accessing this document, but this is just random guess. Can anyone authoritatively (without guesses, with links to respected resources) tell me what does this mean and what are the implications?
This is a common source of confusion, so I wanted to go into a bit more detail.
I have a full working demo in this Gist, and you can view a live version of it thanks to RawGit.
Here's the relevant portion of the service worker code inline, for illustrative purposes:
self.addEventListener('fetch', event => {
if (event.request.url.endsWith('one.js')) {
// Requests for one.js will result in the SW firing off a fetch() request,
// which will be reflected in the DevTools Network panel.
event.respondWith(fetch(event.request));
} else if (event.request.url.endsWith('two.js')) {
// Requests for two.js will result in the SW constructing a new Response object,
// so there won't be an additional network request in the DevTools Network panel.
event.respondWith(new Response('// no-op'));
}
// Requests for anything else won't trigger event.respondWith(), so there won't be
// any SW interaction reflected in the DevTools Network panel.
});
And here's what a filtered version of the Network panel looks like in Chrome 48 when that service worker is in control of a page, and requests are made for one.js, two.js, and three.js:
Our service worker's fetch handler will do one of three things:
If it's a request for one.js, it will fire off a fetch() request for the same URL, and then call event.respondWith() using that response. The first one.js entry in the screenshot, the one with "(from ServiceWorker)" in the "Size" column, is there by virtue of the fact that we called event.respondWith() inside the fetch handler. The second one.js entry in the screenshot, the one with the little gear icon next to it and "(from cache)" in the "Size" column, represents that fetch() request that was made inside the service worker while responding to the event. Since the actual one.js file was already in the HTTP cache at the point I took this screenshot, you see "(from cache)", but if the HTTP cache didn't have that response already, you would see an actual network request along with the response size.
If it's a request for two.js, it will handle the request by constructing a new Response object "from thin air". (Yes, you can do that!) In this case, we are calling event.respondWith(), so there's an entry for two.js with "(from ServiceWorker)" in the "Size" column. But unlike with one.js, we're not using fetch() to populate the response, so there's no additional entry in the Network panel for two.js.
Finally, if it's a request for three.js, our service worker's fetch event handler won't actually call event.respondWith(). From the perspective of the page, and also from the perspective of the Network panel, there's no service worker involvement with that request, which is why there's just a "(from cache)" rather than "(from ServiceWorker)" in the "Size" column.
A service worker is a script that is run by your browser in the background. So Status Code:200 OK (from ServiceWorker) mean that “OK” success code, for GET or HEAD request and this status come from ServiceWorker.
You can read this link to understand more about this.
http://www.html5rocks.com/en/tutorials/service-worker/introduction/
This is normal . To avoid confusion arising out by 200 for every request. Its showing that the request is a SUCCESS but service-worker has responded for the resource / request instead of network/server
I found out that following issue occurs on safari via Javascript, jQuery Ajax:
I make a cors simple request using GET
Server responses with 302
Safari follows redirect but uses OPTIONS instead of GET as method, so it does a preflight request
I would expect that step 3 would also invoke a simple request using GET, which is exactly how it is done in Chrome and Firefox.
The problem is that the server who responses to the request after step 3 can not handle requests with method OPTIONS and therefor fails with status "Method Not Allowed".
Since i have no influence on the server side, i need to force either to not follow the redirect automatically and do it manually instead or somehow tell safari not to switch to OPTIONS.
Is there any way to do one of those options?
I have a javascript web app set up to use long polling with a .net server, using the ajax call:
var _listenTimeout = 5 * 60 * 1000;
//...
$.ajax({
type: "GET",
url: url,
async: true,
cache: false,
dataType: "jsonp",
timeout: _listenTimeout,
success: callback
});
However, there is an issue when the page is open for a while, where requests to the server stop responding. It seems to be in a limbo state, where packets are stuck between the web browser and being sent out of the network to the server.
I've dug around, and I know a couple of things:
The request gets sent because it shows up on the chrome web developer network tab (also chrome://net-internals) and firebug. The status of the request is always pending, and it just stalls in that state.
The request url is correct, because sending the same url through curl returns an immediate response.
It hasn't left my network because there aren't any packets detected using wireshark. The server logs (and wireshark on that side) don't show anything either.
The strange thing is, sometimes it works sporadically, but with a delay of a couple of minutes ie, the browser network log detects the request gets a response (a 204 in my case), and wireshark detects the request being sent (and received on the server end). The delay is the same for both the browser and wireshark ie, the request is made, a delay occurs, then chrome detects a response and wireshare detects packets sent.
A clean refresh of the page also fixes the issue, with the same request/response occurring almost immediately (with the relevant browser network and wireshark logs).
I've tried it on Chrome 21.0.1180.89 and Firefox 14.01.
Is there some browser queue of some sort that gets clogged up in the browser with ajax requests? Or maybe too many concurrent requests? No idea right now...
$.ajax wont make periodic requests. timeout option specifies the delay in making actual request not for polling. read about it here. http://api.jquery.com/jQuery.ajax/. Thats why you are seeing only one ajax request.If you want it manually you have to do it with setTimeout javascript method.
You can call setTimeout in the success and error callbacks so that you can get rid of concurrent ajax requests.