We Keep Coding

Javascript request error, status code 503

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!

fetch from API - specific API errors vs general HTTP errors

I am using fetch() to get results from an API. As I understand it, there's 2 different types of errors:
an error that my API returns specifically: for example "invalid authentication token"
more generic HTTP errors: for example - network timeout or connectivity was interrupted.
Is there a way to determine the nature of the issue, in such a way that I can retry an API command when it makes sense (like poor network connectivity), but not retry it if it's just going to give the same result as the previous time (like an invalid token error)

Is there a way to determine the nature of the issue, in such a way that I can retry an API command when it makes sense (like poor network connectivity), but not retry it if it's just going to give the same result as the previous time (like an invalid token error)
fetch() only throws if there was some error with recieving the data. If your server responded with an error status, you'd have to check that in the then() block.
#Thomas Thanks! So in general if i enter my catch() block of the fetch(), I can treat that as a network issue?
Think the other way around. If you land in the then() part, your server has responded successfully; wether you like that response (200) or not (404).
If you land in the catch() part of the fetch(), something went wrong with the request and a network error is one of the more likely reasons. An invalid url, like "//", would be another reason to throw.

What should be the response code when error is generated by third party application?

I built a web application that basically ask the user for credentials with a form (for a random 3rd party service, knowing which one does not matter).
Once the user filled the form with the 3rd party service app token, a request with the token is sent to the application backend, the backend gets the token and send a request to the 3rd party service in order to check if the token is valid.
At this point the 3rd party service returns a response to the backend with either 200 - {randomObject: object} or 401 - Unauthorized.
So here is my question : If the 3rd party service returns 401, should the backend returns 200 - false or 401 - Unauthorized ?
Me and my colleague have been arguing about this.
My point is that the access to the application backend is authorized and the parameters are correct (a token is present in the request), so the response should be 200 but the content of the response should indicate wether or not the token is valid.
His point is that since the token is not valid (as the 3rd party service tells the backend), the backend should return 401 - Unauthorized.
Just so we're clear, I know that the outcome is in both cases the same, as a matter of fact this functionality already works, I just want to know is there are some sort of convention regarding this specific matter.
Thank you

I would go for either 400 or 401.
401 might be misleading because access to your API was not unauthorized. (especially if your api also requires authentication)
on the other hand 400 might be best :
The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error

I would say it should be a 401 still. The workings of your backend should have no bearing on the application in the sense that its inner workings aren't important to the end user. The fact that your auth service is telling you it isn't valid should be enough for you to throw this error.

On this:
My point is that the access to the application backend is authorized
and the parameters are correct (a token is present in the request), so
the response should be 200
The presence of a token does not mean that the request is valid. 401 Unauthorized should be used, since invalid credentials were provided. From httpstatuses.com:
The request has not been applied because it lacks valid authentication
credentials for the target resource.
If you were thinking it should be a 200 because the credential is not for your service, but for a third-party service and so authorization to your service is not failing, that could be argued, but in that case you still probably don't want to return a 200 but instead a 400 Bad Request since the parameters to successfully complete the API operation are invalid.

I'll buck the trend a bit and say you should return 200.
The status code 401 is related to HTTP authentication. W3C has the following to say on the status code:
The request requires user authentication. The response MUST include a
WWW-Authenticate header field (section 14.47) containing a challenge
applicable to the requested resource. The client MAY repeat the
request with a suitable Authorization header field (section 14.8). If
the request already included Authorization credentials, then the 401
response indicates that authorization has been refused for those
credentials. If the 401 response contains the same challenge as the
prior response, and the user agent has already attempted
authentication at least once, then the user SHOULD be presented the
entity that was given in the response, since that entity might include
relevant diagnostic information.
(source)
Since your server presumably does not use HTTP authentication itself, you won't be returning a WWW-Authenticate header with a challenge, hence you won't be following this spec correctly. The 3rd party API you are calling may do this correctly, but that is by the by. Your user has requested a page from you, not the third party API directly, and they are authorised to do that. Your server has not decided that they are not worthy of a valid response - someone else's server has just told you that their token is not valid.
Given this, I would return a 200. The request has succeeded. Your server is able to return information indicating that the third party API call failed.

How to handle CORS error code?

Edit: I just realized this is a duplicate of Recommended solution for AJAX, CORS, Chrome & HTTP error codes (401,403,404,500), and he tried the idea I propose at the end. But I can't tell if he succeeded (dud user?), and no one else has posted a solution or even a comment, so I think it's worth fishing for new answers.
Problem:
I send a properly-executed (edit: IMproperly-executed. End of story...) CORS request.
The server receives the request and attempts to process it.
The server returns an error response, for example a 422 Unprocessable Entity, along with JSON information about the errors. The idea is that my app could receive this error information and handle it appropriately in the UI.
The browser blocks my error handler from getting the response content, or even getting the status code.
Showing that the browser received the 401 status code but treated it as a CORS security error:
The response object, showing that my code cannot access the response data (data: "", status: 0):
How have other people handled this limitation? My best guess right now is to hijack an HTTP "success" code (2XX) as an error code, and then include the error information in the response. This prevents me from using the ajax error handlers in a normal way, but I'm handling this as a global ajax filter anyway, so this filter would capture the deviant success code and trigger the error handlers instead.

The console message indicates that the server isn't sending the required Access-Control-Allow-Origin header when it sends the 401 response code.
You won't be able to use the CORS error handler to inject content into the DOM unless you fix that.
The server is likely sending the header correctly on responses with a 200 response code. It needs to do it for other response codes, though, if you wish to use data from those response codes.
Fix that on the server end before making design compromises on the client side. That may solve your problem straight away.

It seems it's an opaque response where you can't obtain the headers or the response. And everything is set to null or empty.
https://developer.mozilla.org/en-US/docs/Web/API/Response/type
Or maybe in the server you should add:
Access-Control-Allow-Origin: *

Very late answer but in case someone wants to check whether an error occurred while sending an XMLHttpRequest and then take appropriate actions (on the CLIENT side), then this is a quick workaround:
try{
request.send();
}catch(err){
if(e.toString().startsWith("NetworkError")){
//pasre the string to check error code
//and take appropriate actions
}
}
This is needed because the onreadystatechange function doesn't get executed when a NetworkError occurs and, in fact, the whole script is terminated.

What's the RESTful way to check whether the client can access a resource?

I'm trying to determine the best practice in a REST API for determining whether the client can access a particular resource. Two quick example scenarios:
A phone directory lookup service. Client looks up a phone number by accessing eg.
GET http://host/directoryEntries/numbers/12345
... where 12345 is the phone number to try and find in the directory. If it exists, it would return information like the name and address of the person whose phone number it is.
A video format shifting service. Client submits a video in one format to eg.
POST http://host/videos/
... and receives a 'video GUID' which has been generated by the server for this video. Client then checks eg.
GET http://host/videos/[GUID]/flv
... to get the video, converted into the FLV format, if the converted version exists.
You'll notice that in both cases above, I didn't mention what should happen if the resource being checked for doesn't exist. That's my question here. I've read in various other places that the proper RESTful way for the client to check whether the resource exists here is to call HEAD (or maybe GET) on the resource, and if the resource doesn't exist, it should expect a 404 response. This would be fine, except that a 404 response is widely considered an 'error'; the HTTP/1.1 spec states that the 4xx class of status code is intended for cases in which the client 'seems to have erred'. But wait; in these examples, the client has surely not erred. It expects that it may get back a 404 (or others; maybe a 403 if it's not authorized to access this resource), and it has made no mistake whatsoever in requesting the resource. The 404 isn't intended to indicate an 'error condition', it is merely information - 'this does not exist'.
And browsers behave, as the HTTP spec suggests, as if the 404 response is a genuine error. Both Google Chrome and Firebug's console spew out a big red "404 Not Found" error message into the Javascript console each time a 404 is received by an XHR request, regardless of whether it was handled by an error handler or not, and there is no way to disable it. This isn't a problem for the user, as they don't see the console, but as a developer I don't want to see a bunch of 404 (or 403, etc.) errors in my JS console when I know perfectly well that they aren't errors, but information being handled by my Javascript code. It's line noise. In the second example I gave, it's line noise to the extreme, because the client is likely to be polling the server for that /flv as it may take a while to compile and the client wants to display 'not compiled yet' until it gets a non-404. There may be a 404 error appearing in the JS console every second or two.
So, is this the best or most proper way we have with REST to check for the existence of a resource? How do we get around the line noise in the JS console? It may well be suggested that, in my second example, a different URI could be queried to check the status of the compilation, like:
GET http://host/videos/[GUID]/compileStatus
... however, this seems to violate the REST principle a little, to me; you're not using HTTP to its full and paying attention to the HTTP headers, but instead creating your own protocol whereby you return information in the body telling you what you want to know instead, and always return an HTTP 200 to shut the browser up. This was a major criticism of SOAP - it tries to 'get around' HTTP rather than use it to its full. By this principle, why does one ever need to return a 404 status code? You could always return a 200 - of course, the 200 is indicating that the a resource's status information is available, and the status information tells you what you really wanted to know - the resource was not found. Surely the RESTful way should be to return a 404 status code.
This mechanism seems even more contrived if we apply it to the first of my above examples; the client would perhaps query:
GET http://host/directoryEntries/numberStatuses/12345
... and of course receive a 200; the number 12345's status information exists, and tells you... that the number is not found in the directory. This would mean that ANY number queried would be '200 OK', even though it may not exist - does this seem like a good REST interface?
Am I missing something? Is there a better way to determine whether a resource exists RESTfully, or should HTTP perhaps be updated to indicate that non-2xx status codes should not necessarily be considered 'errors', and are just information? Should browsers be able to be configured so that they don't always output non-2xx status responses as 'errors' in the JS console?
PS. If you read this far, thanks. ;-)

It is perfectly okay to use 404 to indicate that resource is not found. Some quotes from the book "RESTful Web Services" (very good book about REST by the way):
404 indicates that the server can’t map the client’s URI to a
resource. [...] A web service may use a 404 response as a signal to
the client that the URI is “free”; the client can then create a new
resource by sending a PUT request to that URI. Remember that a 404 may
be a lie to cover up a 403 or 401. It might be that the resource
exists, but the server doesn’t want to let the client know about it.
Use 404 when service can't find requested resource, do not overuse to indicate the errors which are actually not relevant to the existence of resource. Also, client may "query" the service to know whether this URI is free or not.
Performing long-running operations like encoding of video files
HTTP has a synchronous request-response model. The client opens an
Internet socket to the server, makes its request, and keeps the socket
open until the server has sent the response. [...]
The problem is not all operations can be completed in the time we
expect an HTTP request to take. Some operations take hours or days. An
HTTP request would surely be timed out after that kind of inactivity.
Even if it didn’t, who wants to keep a socket open for days just
waiting for a server to respond? Is there no way to expose such
operations asynchronously through HTTP?
There is, but it requires that the operation be split into two or more
synchronous requests. The first request spawns the operation, and
subsequent requests let the client learn about the status of the
operation. The secret is the status code 202 (“Accepted”).
So you could do POST /videos to create a video encoding task. The service will accept the task, answer with 202 and provide a link to a resource describing the state of the task.
202 Accepted
Location: http://tasks.example.com/video/task45543
Client may query this URI to see the status of the task. Once the task is complete, representation of resource will become available.

I think you have changed the semantics of the request.
With a RESTful architecture, you are requesting a resource. Therefore requesting a resource that does not exist or not found is considered an error.
I use:
404 if GET http://host/directoryEntries/numbers/12345 does not exist.
400 is actually a bad request 400 Bad Request
Perhaps, in your case you could think about searching instead.
Searches are done with query parameters on a collection of resources
What you want is
GET http://host/directoryEntries/numbers?id=1234
Which would return 200 and an empty list if none exist or a list of matches.

IMO the client has indeed erred in requesting a non-existent resource. In both your examples the service can be designed in a different way so an error can be avoided on the client side. For example, in the video conversion service as the GUID has already been assigned, the message body at videos/id can contain a flag indicating whether the conversion was done or not.
Similarly, in the phone directory example, you are searching for a resource and this can be handled through something like /numbers/?search_number=12345 etc. so that the server returns a list of matching resources which you can then query further.
Browsers are designed for working with the HTTP spec and showing an error is a genuine response (pretty helpful too). However, you need to think about your Javascript code as a separate entity from the browser. So you have your Javascript REST client which knows what the service is like and the browser which is sort of dumb with regards to your service.
Also, REST is independent of protocols in theory. HTTP happens to be the most common protocol where REST is used. Another example I can think of is Android content providers whose design is RESTful but not dependent on HTTP.

I've only ever seen GET/HEAD requests return 404 (Not Found) when a resource doesn't exist. I think if you are trying to just get a status of a resource a head request would be fine as it shouldn't return the body of a resource. This way you can differentiate between requests where you are trying to retrieve the resource and requests where you are trying to check for their existance.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
Edit: I remember reading about an alternative solution by adding a header to the original request that indicated how the server should handle 404 errors. Something along the lines of responding with 200, but an empty body.