I am using next.js and I need to send an AJAX request (I am using isomorphic-unfetch). Some cases the response is with 302 HTTP status code and I need to redirect to the URL that comes in response. For redirecting, I have tried with Router.push(url) and window.location.href=url due is a client redirection.
The problem is that in IE11 appears the error (other browsers works well)
The redirection is done but it takes about 10 seconds. I was googling and found this SCRIPT7002: XMLHttpRequest: Network Error 0x2ef3, Could not complete the operation due to error 00002ef3 that describe a bit my problem but none of the proposed solutions fixed my problem.
Other posts suggest changing the status response but I have no control to the requested endpoint so I can't change anything.
Any ideas on how to solve this?
Related
I am using a plugin on a WordPress website which is supposed to feed gravity forms submissions into hubspot however, on submission I get the following error:
PHP Fatal error: Uncaught GuzzleHttp\Exception\ClientException: Client error: POST https://forms.hubspot.com/uploads/form/v2/XXXXXX/97d44f1e-XXXX-XXXX-XXXX-e4c453843854 resulted in a 404 Not Found response:
I've nullified the URL.
I've searched this error and read through many, many GitHub threads but no seem of any use to me - they're all about other people's bespoke implementations. Can anybody here shed any light on this for me? Is there any more information I can post to allow anybody to help me investigate deeper?
Some temp fixes I've seen circulate:
1) On your Hubspot forms, make sure they are using Thank You messages and NOT the redirect to page feature (neither are actually functional if you are using only this plugin making API requests and not using for form embed code etc provided by HubSpot)
2) Save / update your forms in HubSpot
Since doing the above (there was a mixture of the two in our case, we have not caught any further errors for the past couple days) Jury is still out on what is the true issue behind this.
Details:
I hit this issue as well. Guzzle is throwing the error after seeing the HS response. This Guzzle client was not used in the older version of the plugin, so thinking that either the request was different in previous versions (prior to v3) or HubSpot was throwing a 404 response before and it was being ignored. Data (in my testing) is still posting correctly to the HubSpot API and shown/updated in the Contact record database. But website users end up seeing a 500 error due to this issue. (As a result the analytics scripts on the thank you page never get fired so we caught this seeing a drop in GA) I'm assuming the plugin could be coded around this to ignore the exception, but still no idea why it is being provided as a response in the first place.
I am trying to create a surveymonkey webhook to receive my survey response and i am passing my SugarCRM custom entry point URL as "Subscription Url". But i am getting error " 'mycustomEntryPointUrl' did not return a success status code. Status code is 301". My Entry point is working fine if i run it in browser using its URL also my Sugar is working smoothly.
So, i just want to know any other reason which can cause this error.
Yes so HTTP status code 301 means the page has moved permanently. If you visit it in your browser, for example, you would see a network request to the page specified with a status code of 301, then a second one to the new page. Our API request won't do any redirect, so if a 301 is returned it will raise an error.
This sometimes happens when you go to a page with http and then it redirects to https due to rules on your server.
You also want to make sure your subscription URL supports a HEAD request without any redirect.
Simply souncloud servers responds with 502 Bad Gateway error on a /playlists call to API with client_id and user_id parameters. Issue regards a specific user, so maybe something it's messed up on server or on profile.. but how can I resolve?! There's no recovery procedure or similar to try things works again?
I ran into this issue myself and believe I have found the root cause. After trying the playlists query in browser & curl I was able to get the valid data response (JSON).
Turns out Soundcloud includes all the tracks information of each playlist! I have the max (500) tracks in some playlists so the response payload size must be the issue. It must also be why we get an occasional timeout response.
I will see what I can do about limiting the data size in the response and may try other libraries (I'm using soundcloud-ruby.)
I see that this question has been asked before but no solution has been provided.
I am getting nothing but 500 Internal Server Error since yesterday when I use following link:
http://apps.facebook.com/myappID
Yes, I already tried clearing up my cache & cookies so don't even bother asking me this. I have added my app link in the Canvas URL which should show up after I click on the app URL but nothing but that 500 HTTP error. I tried on all browsers and even asked few of my friends too and they said same error.
I thought it was an error on Facebook but I don't see how it's not being fixed for a day now.
Any help? Thank you.
The 500 Internal Server Error is a very general HTTP status code that means something has gone wrong on the web site's server but the server could not be more specific on what the exact problem is.
So its a "server-side" error, meaning the problem is not with your PC or Internet connection but instead is a problem with the web site's server.
Maybe you should contact facebook help center.
I just ran into a similar situation and found that when I reduced the limit in my GET call to 20 rather than 500 the server responded well.
https://graph.facebook.com/v2.0/6558867050/posts?limit=20
I need to use a facebook application but my web page return response 206 instead 200,
so that the facebook application return http code 500.
I tested with http://developers.facebook.com/tools/debug/og/object?q=http://adserver.leadhouse.net/test/test/index.php and return 206 instead joomla.it return 200
when they are same curl -I response datae
I tested with this perl script: http://pastebin.com/NCDv9eTh
and my page is vulnerable instead joomla.it is good.
I think that my answer is very close between
Facebook debugger : Response 206
and Apache Webserver security and optimization tips
but I don't understand how change my apache configuration.
the solution is into this page:
www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.2
with similar code:
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
or
httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
how can I make it less vulnerable to my web pages?
I have no idea what kind of “vulnerability” you are talking about here.
Facebook debugger showing a response status code 206 is normal – because the debugger tries to only request the first x (K)Bytes from your URL. If your server accepts such range requests and answers them correctly, then the response code will be 206.
There is no vulnerability in that.
If this causes you any other problems with your site – then please describe them in a manner that makes them comprehensible.
Yes, everything is started with debugging facebook: dialog send return 500 http code with my page return 206 http code.
And my curiosity is focused on DoS vulnerability of http code 206 when I tested perl script http://pastebin.com/NCDv9eTh
I report some significant phrase about apache documentation:
This vulnerability concerns a 'Denial of Service' attack. This means
that a remote attacker, under the right circumstances, is able to slow
your service or server down to a crawl or exhausting memory available
to serve requests, leaving it unable to serve legitimate clients in a
timely manner.
There are no indications that this leads to a remote exploit; where a
third party can compromise your security and gain foothold of the
server itself. The result of this vulnerability is purely one of
denying service by grinding your server down to a halt and refusing
additional connections to the server.
so that LimitRequestFieldSize workaround was insufficient,
you could modify Range parameters consulting Mitigation paragraph
about apache wiki documentation: http://wiki.apache.org/httpd/CVE-2011-3192
You obtain switch between return http code: from 206 to 200.
You best apache configuration, but you're still exposed to DoS vulnerability.
I added mod_headers with this line:
RequestHeader unset Range
and now my page return http code 200.
And to limit exhausting memory available to serve requests,
I limit ip connections adding mod_limitipconn with this code:
MaxConnPerIP 10