- QuickBlox «Request failed: client error (422)» on some devices #452
- HTTP response status codes
- Information responses
- Successful responses
- Redirection messages
- Client error responses
- Server error responses
- HTTP Status Codes
- 1xx Status Codes [Informational]
- 2xx Status Codes [Success]
- 3xx Status Codes [Redirection]
- 4xx Status Codes (Client Error)
- 5xx Status Codes (Server Error)
- 6. REST Specific HTTP Status Codes
- 200 (OK)
- 201 (Created)
- 202 (Accepted)
- 204 (No Content)
- 301 (Moved Permanently)
- 302 (Found)
- 303 (See Other)
- 304 (Not Modified)
- 307 (Temporary Redirect)
- 400 (Bad Request)
- 401 (Unauthorized)
- 403 (Forbidden)
- 404 (Not Found)
- 405 (Method Not Allowed)
- 406 (Not Acceptable)
- 412 (Precondition Failed)
- 415 (Unsupported Media Type)
- 500 (Internal Server Error)
QuickBlox «Request failed: client error (422)» on some devices #452
Error Domain=com.alamofire.error.serialization.response Code=-1011 «Request failed: client error (422)» UserInfo=
«Access-Control-Allow-Origin» = «*»;
«Cache-Control» = «no-cache»;
Connection = «keep-alive»;
«Content-Length» = 37;
«Content-Type» = «application/json; charset=utf-8»;
Date = «Tue, 17 May 2016 08:36:18 GMT»;
«QuickBlox-REST-API-Version» = «0.1.1»;
Server = «nginx/1.8.1»;
Status = «422 Unprocessable Entity»;
«X-Rack-Cache» = «invalidate, pass»;
«X-Request-Id» = 0517162073ceae4d87d5ebf3df20d1d1;
«X-Runtime» = «0.007235»;
«X-UA-Compatible» = «IE=Edge,chrome=1»;
> >, NSErrorFailingURLKey=https://api.quickblox.com/session.json, NSLocalizedRecoverySuggestion=<"errors":<"base":["Bad timestamp"]>>, com.alamofire.serialization.response.error.data= , NSLocalizedDescription=Request failed: client error (422)>
The text was updated successfully, but these errors were encountered:
Bad timestamp means that you send invalid timestamp value on session creation, which is based on your phone time. Your device time shouldn’t differ from server more than 2 hours.
We suggest you synchronize time on your devices with NTP service or just set tick 2 checkboxes in Settings in your device: Automatic date & time and Automatic time zone.
That problem has been solved.
But we are facing a new problem when we used our credential then the call is not connecting and produce an an error «Destroy dialing timer».but is connecting if we used existing credentials.only problem occur when we used our credentials
Seems like your new issue does not have any reference to this one anymore. Please create a separate one with full WebRTC logs (according to your post you have problems with logs). Thank you.
I want to integrate chat and pushnotification in my ios app ,i am facing following issue
HTTP response status codes
HTTP response status codes indicate whether a specific HTTP request has been successfully completed. Responses are grouped in five classes:
The status codes listed below are defined by RFC 9110.
Note: If you receive a response that is not in this list, it is a non-standard response, possibly custom to the server’s software.
This interim response indicates that the client should continue the request or ignore the response if the request is already finished.
This code is sent in response to an Upgrade request header from the client and indicates the protocol the server is switching to.
This code indicates that the server has received and is processing the request, but no response is available yet.
This status code is primarily intended to be used with the Link header, letting the user agent start preloading resources while the server prepares a response.
The request succeeded. The result meaning of «success» depends on the HTTP method:
- GET : The resource has been fetched and transmitted in the message body.
- HEAD : The representation headers are included in the response without any message body.
- PUT or POST : The resource describing the result of the action is transmitted in the message body.
- TRACE : The message body contains the request message as received by the server.
The request succeeded, and a new resource was created as a result. This is typically the response sent after POST requests, or some PUT requests.
The request has been received but not yet acted upon. It is noncommittal, since there is no way in HTTP to later send an asynchronous response indicating the outcome of the request. It is intended for cases where another process or server handles the request, or for batch processing.
This response code means the returned metadata is not exactly the same as is available from the origin server, but is collected from a local or a third-party copy. This is mostly used for mirrors or backups of another resource. Except for that specific case, the 200 OK response is preferred to this status.
There is no content to send for this request, but the headers may be useful. The user agent may update its cached headers for this resource with the new ones.
Tells the user agent to reset the document which sent this request.
This response code is used when the Range header is sent from the client to request only part of a resource.
Conveys information about multiple resources, for situations where multiple status codes might be appropriate.
Used inside a response element to avoid repeatedly enumerating the internal members of multiple bindings to the same collection.
The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.
The request has more than one possible response. The user agent or user should choose one of them. (There is no standardized way of choosing one of the responses, but HTML links to the possibilities are recommended so the user can pick.)
The URL of the requested resource has been changed permanently. The new URL is given in the response.
This response code means that the URI of requested resource has been changed temporarily. Further changes in the URI might be made in the future. Therefore, this same URI should be used by the client in future requests.
The server sent this response to direct the client to get the requested resource at another URI with a GET request.
This is used for caching purposes. It tells the client that the response has not been modified, so the client can continue to use the same cached version of the response.
Defined in a previous version of the HTTP specification to indicate that a requested response must be accessed by a proxy. It has been deprecated due to security concerns regarding in-band configuration of a proxy.
This response code is no longer used; it is just reserved. It was used in a previous version of the HTTP/1.1 specification.
The server sends this response to direct the client to get the requested resource at another URI with same method that was used in the prior request. This has the same semantics as the 302 Found HTTP response code, with the exception that the user agent must not change the HTTP method used: if a POST was used in the first request, a POST must be used in the second request.
This means that the resource is now permanently located at another URI, specified by the Location: HTTP Response header. This has the same semantics as the 301 Moved Permanently HTTP response code, with the exception that the user agent must not change the HTTP method used: if a POST was used in the first request, a POST must be used in the second request.
Client error responses
The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
Although the HTTP standard specifies «unauthorized», semantically this response means «unauthenticated». That is, the client must authenticate itself to get the requested response.
This response code is reserved for future use. The initial aim for creating this code was using it for digital payment systems, however this status code is used very rarely and no standard convention exists.
The client does not have access rights to the content; that is, it is unauthorized, so the server is refusing to give the requested resource. Unlike 401 Unauthorized , the client’s identity is known to the server.
The server cannot find the requested resource. In the browser, this means the URL is not recognized. In an API, this can also mean that the endpoint is valid but the resource itself does not exist. Servers may also send this response instead of 403 Forbidden to hide the existence of a resource from an unauthorized client. This response code is probably the most well known due to its frequent occurrence on the web.
The request method is known by the server but is not supported by the target resource. For example, an API may not allow calling DELETE to remove a resource.
This response is sent when the web server, after performing server-driven content negotiation, doesn’t find any content that conforms to the criteria given by the user agent.
This is similar to 401 Unauthorized but authentication is needed to be done by a proxy.
This response is sent on an idle connection by some servers, even without any previous request by the client. It means that the server would like to shut down this unused connection. This response is used much more since some browsers, like Chrome, Firefox 27+, or IE9, use HTTP pre-connection mechanisms to speed up surfing. Also note that some servers merely shut down the connection without sending this message.
This response is sent when a request conflicts with the current state of the server.
This response is sent when the requested content has been permanently deleted from server, with no forwarding address. Clients are expected to remove their caches and links to the resource. The HTTP specification intends this status code to be used for «limited-time, promotional services». APIs should not feel compelled to indicate resources that have been deleted with this status code.
Server rejected the request because the Content-Length header field is not defined and the server requires it.
The client has indicated preconditions in its headers which the server does not meet.
Request entity is larger than limits defined by server. The server might close the connection or return an Retry-After header field.
The URI requested by the client is longer than the server is willing to interpret.
The media format of the requested data is not supported by the server, so the server is rejecting the request.
The range specified by the Range header field in the request cannot be fulfilled. It’s possible that the range is outside the size of the target URI’s data.
This response code means the expectation indicated by the Expect request header field cannot be met by the server.
The server refuses the attempt to brew coffee with a teapot.
The request was directed at a server that is not able to produce a response. This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI.
The request was well-formed but was unable to be followed due to semantic errors.
The resource that is being accessed is locked.
The request failed due to failure of a previous request.
Indicates that the server is unwilling to risk processing a request that might be replayed.
The server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server sends an Upgrade header in a 426 response to indicate the required protocol(s).
The origin server requires the request to be conditional. This response is intended to prevent the ‘lost update’ problem, where a client GET s a resource’s state, modifies it and PUT s it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.
The user has sent too many requests in a given amount of time («rate limiting»).
The server is unwilling to process the request because its header fields are too large. The request may be resubmitted after reducing the size of the request header fields.
The user agent requested a resource that cannot legally be provided, such as a web page censored by a government.
Server error responses
The server has encountered a situation it does not know how to handle.
The request method is not supported by the server and cannot be handled. The only methods that servers are required to support (and therefore that must not return this code) are GET and HEAD .
This error response means that the server, while working as a gateway to get a response needed to handle the request, got an invalid response.
The server is not ready to handle the request. Common causes are a server that is down for maintenance or that is overloaded. Note that together with this response, a user-friendly page explaining the problem should be sent. This response should be used for temporary conditions and the Retry-After HTTP header should, if possible, contain the estimated time before the recovery of the service. The webmaster must also take care about the caching-related headers that are sent along with this response, as these temporary condition responses should usually not be cached.
This error response is given when the server is acting as a gateway and cannot get a response in time.
The HTTP version used in the request is not supported by the server.
The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.
The method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request.
The server detected an infinite loop while processing the request.
Further extensions to the request are required for the server to fulfill it.
Indicates that the client needs to authenticate to gain network access.
HTTP Status Codes
Last Updated : December 17, 2021
By : Lokesh Gupta
REST APIs use the Status-Line part of an HTTP response message to inform clients of their request’s overarching result. RFC 2616 defines the Status-Line syntax as shown below:
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
HTTP defines these standard status codes that can be used to convey the results of a client’s request. The status codes are divided into five categories.
- 1xx: Informational – Communicates transfer protocol-level information.
- 2xx: Success – Indicates that the client’s request was accepted successfully.
- 3xx: Redirection – Indicates that the client must take some additional action in order to complete their request.
- 4xx: Client Error – This category of error status codes points the finger at clients.
- 5xx: Server Error – The server takes responsibility for these error status codes.
1xx Status Codes [Informational]
2xx Status Codes [Success]
3xx Status Codes [Redirection]
4xx Status Codes (Client Error)
5xx Status Codes (Server Error)
6. REST Specific HTTP Status Codes
It indicates that the REST API successfully carried out whatever action the client requested and that no more specific code in the 2xx series is appropriate.
Unlike the 204 status code, a 200 response should include a response body. The information returned with the response is dependent on the method used in the request, for example:
- GET an entity corresponding to the requested resource is sent in the response;
- HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;
- POST an entity describing or containing the result of the action;
- TRACE an entity containing the request message as received by the end server.
A REST API responds with the 201 status code whenever a resource is created inside a collection. There may also be times when a new resource is created as a result of some controller action, in which case 201 would also be an appropriate response.
The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field.
The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with a 202 (Accepted) response instead.
A 202 response is typically used for actions that take a long while to process. It indicates that the request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, or even maybe disallowed when processing occurs.
Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent’s connection to the server persist until the process is completed.
The entity returned with this response SHOULD include an indication of the request’s current status and either a pointer to a status monitor (job queue location) or some estimate of when the user can expect the request to be fulfilled.
204 (No Content)
The 204 status code is usually sent out in response to a PUT , POST , or DELETE request when the REST API declines to send back any status message or representation in the response message’s body.
An API may also send 204 in conjunction with a GET request to indicate that the requested resource exists, but has no state representation to include in the body.
If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent’s active document view. However, any new or updated metainformation SHOULD be applied to the document currently in the user agent’s dynamic view.
The 204 response MUST NOT include a message-body and thus is always terminated by the first empty line after the header fields.
301 (Moved Permanently)
The 301 status code indicates that the REST API’s resource model has been significantly redesigned, and a new permanent URI has been assigned to the client’s requested resource. The REST API should specify the new URI in the response’s Location header, and all future requests should be directed to the given URI.
You will hardly use this response code in your API as you can always use the API versioning for the new API while retaining the old one.
The HTTP response status code 302 Found is a common way of performing URL redirection. An HTTP response with this status code will additionally provide a URL in the Location header field. The user agent (e.g., a web browser) is invited by a response with this code to make a second. Otherwise identical, request to the new URL specified in the location field.
Many web browsers implemented this code in a manner that violated this standard, changing the request type of the new request to GET, regardless of the type employed in the original request (e.g., POST). RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.
303 (See Other)
A 303 response indicates that a controller resource has finished its work, but instead of sending a potentially unwanted response body, it sends the client the URI of a response resource. The response can be the URI of the temporary status message, or the URI to some already existing, more permanent, resource.
Generally speaking, the 303 status code allows a REST API to send a reference to a resource without forcing the client to download its state. Instead, the client may send a GET request to the value of the Location header.
The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.
304 (Not Modified)
This status code is similar to 204 (“No Content”) in that the response body must be empty. The critical distinction is that 204 is used when there is nothing to send in the body, whereas 304 is used when the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match.
In such a case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.
Using this saves bandwidth and reprocessing on both the server and client, as only the header data must be sent and received in comparison to the entirety of the page being re-processed by the server, then sent again using more bandwidth of the server and client.
307 (Temporary Redirect)
A 307 response indicates that the REST API is not going to process the client’s request. Instead, the client should resubmit the request to the URI specified by the response message’s Location header. However, future requests should still use the original URI.
A REST API can use this status code to assign a temporary URI to the client’s requested resource. For example, a 307 response can be used to shift a client request over to another host.
The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). If the 307 status code is received in response to a request other than GET or HEAD , the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
400 (Bad Request)
400 is the generic client-side error status, used when no other 4xx error code is appropriate. Errors can be like malformed request syntax, invalid request message parameters, or deceptive request routing etc.
The client SHOULD NOT repeat the request without modifications.
A 401 error response indicates that the client tried to operate on a protected resource without providing the proper authorization. It may have provided the wrong credentials or none at all. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.
The client MAY repeat the request with a suitable Authorization header field. 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.
A 403 error response indicates that the client’s request is formed correctly, but the REST API refuses to honor it, i.e., the user does not have the necessary permissions for the resource. A 403 response is not a case of insufficient client credentials; that would be 401 (“Unauthorized”).
Authentication will not help, and the request SHOULD NOT be repeated. Unlike a 401 Unauthorized response, authenticating will make no difference.
404 (Not Found)
The 404 error status code indicates that the REST API can’t map the client’s URI to a resource but may be available in the future. Subsequent requests by the client are permissible.
No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
405 (Method Not Allowed)
The API responds with a 405 error to indicate that the client tried to use an HTTP method that the resource does not allow. For instance, a read-only resource could support only GET and HEAD, while a controller resource might allow GET and POST, but not PUT or DELETE.
A 405 response must include the Allow header, which lists the HTTP methods that the resource supports. For example:
406 (Not Acceptable)
The 406 error response indicates that the API is not able to generate any of the client’s preferred media types, as indicated by the Accept request header. For example, a client request for data formatted as application/xml will receive a 406 response if the API is only willing to format data as application/json .
If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.
412 (Precondition Failed)
The 412 error response indicates that the client specified one or more preconditions in its request headers, effectively telling the REST API to carry out its request only if certain conditions were met. A 412 response indicates that those conditions were not met, so instead of carrying out the request, the API sends this status code.
415 (Unsupported Media Type)
The 415 error response indicates that the API is not able to process the client’s supplied media type, as indicated by the Content-Type request header. For example, a client request including data formatted as application/xml will receive a 415 response if the API is only willing to process data formatted as application/json .
For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.
500 (Internal Server Error)
500 is the generic REST API error response. Most web frameworks automatically respond with this response status code whenever they execute some request handler code that raises an exception.
A 500 error is never the client’s fault, and therefore, it is reasonable for the client to retry the same request that triggered this response and hope to get a different response.
The API response is the generic error message, given when an unexpected condition was encountered and no more specific message is suitable.