Since few days, I'm getting an error while requesting ways with the tag 'natural' using Overpass-Turbo.
Here's an example of my requests: http://overpass-turbo.eu/s/fEL
When I execute the request, I'm getting an ajax error: 'Request rejected. (e.g. server not found, request blocked by browser addon, request redirected, internal server errors, etc.)'.
This kind of request used to work very well before. The same request on nodes or relations work, it's only happening with ways tagged 'natural' (and maybe other tags). The error is the same using the webapp Overpass-Turbo.eu or requesting other servers such as http://overpass-api.de/api/interpreter, http://overpass.osm.rambler.ru/cgi/interpreter or http://api.openstreetmap.fr/oapi/interpreter.
I don't know if there are internal issues in Overpass servers or OpenStreetMap database, or if overpass language has been modified, so if somebody has any further information, I would be interested to know it.
This was caused by a recent regression, which has already been fixed. Please see this post for details. Your query should be running fine by now.
Related
Why is error 410 considered a user error (4xx) and not a redirect (3xx) or a server error (5xx)?
I request a payload from a server, and the server returns a link. I copy the link and the link gives 410? It isn't my fault to verify the link actually exists on their server. But at the same time, from the server's point of view the error originated from me, as I accessed something that doesn't exist, similar to 404 where I access something that was never there.
Can anyone help me understand the decision behind this?
Code 410
"410 Gone" client error response code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent.
If you don't know whether this condition is temporary or permanent, a 404 status code should be used instead.
Why is error 410 a user error and not a server error?
It's not a "user" error, it's a client error; but yeah, that's a lousy label. The labels reflect the client-server architectural constraint, but it might be better to use labels that point more directly at the contents of the request, rather than the client (or the user).
In practice, it's a client error for the same reason that 404 is a client error; it is specifically calling attention to the target resource of the HTTP request.
In the context of the web, it does make some (imperfect) sense - the client followed a broken link (which could be a consequence of the server's current representations, but might also come from following links in stale representations, following stale bookmarks, a spelling error in a representation provided by a different server, etc).
It's not a question of fault, it just means that the request should not be considered to ever work in the future (it shouldn't be retried). Whereas a server error (like a 5xx error) could be retried periodically and should eventually work sometime in the future since the request itself is considered valid.
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.
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 have just set up a custom tab on my page for the first time. I have thoroughly followed the setup guide and seem to have everything on the Facebook side setup correctly.
However when I view my page it throws the following error:
Method Not Allowed The requested method GET is not allowed for the
URL /Facebook/index.html. Additionally, a 404 Not Found error was
encountered while trying to use an ErrorDocument to handle the
request. Apache/1.3.41 Server at feebnaturals.com.au Port 80
I believe it may be some kind of Apache server config issue, however I'm not that Apache savvy, so not sure where to start.
I had the same problem, but instead of GET, it was POST method which was not allowed. This is a setting on your server. Not server savvy myself, but it seems that my provider didn't allow this method on html-page, but makes no problem on doing the same for php-pages. So all I did was rename my page from .html to .php, updated the app settings in facebook and all works fine now.
This is definitely an error on your side, check your server logs and see what they say - it looks like you've configured the page to only work via a POST request and it's being requested in a GET request