Error 400: Bad request

The client did not send a correct request to the server. This is a client error, such as a malformed request syntax, invalid request, message framing, or deceptive request routing. For example, if the request contains a special character that is not correctly URL encoded (or percent-encoded), the HTTP 400 error is returned.

If you're getting an HTTP error when using the CIS API, make sure that you are using the correct syntax, the correct parameters, and correct body for your API call.

Error 401: Unauthorized

The request was sent without the proper authentication credentials.

Error 403: Forbidden

If you're seeing a 403 error without CIS branding, this is always returned directly from the origin web server, not CIS, and is generally related to permission rules on your server. The top reasons for this error are:

• Permission rules you have set on the origin web server (in the Apache .htaccess for example)
• Mod_security rules
• IP deny rules. Ensure that CIS's IP ranges aren't being blocked.

CIS will serve 403 responses if the request violated either a default WAF managed rule or a WAF managed rule enabled for that particular zone.

Resolution If you're seeing a 403 response that contains CIS branding in the response body, this is the HTTP response code returned along with security features:

• WAF custom or managed rules with the challenge or block action
• Security level that is set to Medium by default
• Most 1xxx CIS error codes
• The Browser Integrity Check

Error 404: Not found

The origin server was unable or unwilling to find the resource requested. This usually means the host server couldn't find the resource. To serve a more permanent version of this error, use a 410 error code.

These errors typically occur when someone mistypes a URL on your site when there is a broken link from another page, when a page that previously existed is moved or removed, or there is an error when a search engine indexes your site. For a typical site, these errors account for approximately 3% of the total page views, but they're often untracked by traditional analytics platforms.

Website owners usually implement a custom page to be served when this error is generated.

Resolution CIS does not generate 404 errors for customer websites. CIS only proxies the request from the origin server. When you see a 404 for your site, contact your hosting provider for help.

Error 405: Method not allowed

The origin server is aware of the requested resource, but the request method is not supported.

Resolution The origin server must also provide an Allow header with a list of supported targets for that resource.

Error 406: Not acceptable

The server can't produce a response that matches the list of acceptable values defined in the request's content negotiation headers, and the server is unwilling to supply a default representation.

Resolution Instead of generating this error, you can serve the less-preferred method to the User-Agent.

Error 407: Authentication required

The client did not send the required authentication with the request.

Resolution Retry the request with the necessary authentication.

Error 408: Request timeout

The origin server did not receive the complete request in a reasonable time. This error implies that the server does not want to wait and continue the connection.

Resolution This error is not common because servers typically use the "close" connection option.

Error 409: Conflict

The request did not complete because of a conflict with the current state of the resource. This error typically happens on a PUT request where multiple clients are attempting to edit the same resource.

Resolution The server should generate a payload that includes enough information for the client to recognize the source of the conflict. Clients can and should try the request again.

CIS generates and serves a 409 response for an Error 1001: DNS Resolution Error.

Error 410: Gone

The resource requested is permanently missing at the origin.

Resolution The server is suggesting the links reference the resource should be removed. The server is not qualified to use this status code instead of a 404 response, or required to have this response for any specific period of time.

Error 411: Length required

The client did not define the Content-Length of the request body in the headers, and this parameter is required to obtain the resource.

Resolution The client can resend the request after adding the header field.

Error 412: Precondition failed

The server denies the request because the resource failed to meet the conditions specified by the client.

For an example of version control, a client is modifying an existing resource and sets the If-Unmodified-Since header to match the date that the client downloaded the resource and began edits. If the resource was edited (likely by another client) after this date and before the upload of the edits, this response is generated because the date of the last edit comes after the date set in If-Unmodified-Since by the client.

Resolution CIS will serve this response.

Error 413: Payload too large

Refusal from the server to process the request because the payload sent from the client is larger than the server accepts. The server can close the connection.

If this refusal happens only temporarily, then the server should send a Retry-After header to specify when the client should try the request again.

The upload limit for the CIS depends on your plan. If you exceed this limit, your API call receives a 413 Request Entity Too Large error.

Resolution If you require a larger upload, break up requests into smaller chunks, change your DNS record to DNS-only, or upgrade your plan.

Error 414: URI too long

Refusal from the server that the URI was too long to be processed. For example, if a client is attempting a GET request with an unusually long URI after a POST, this can be interpreted as a security risk and a 414 error is generated.

Resolution CIS will generate this response for a URI longer than 32KB.

Error 415: Unsupported media type

Refusal from the server to process the format of the current payload. One way to identify and fix this issue is to look at the Content-Type or Content-Encoding headers sent in the client's request.

Error 416: Range not satisfiable

The 416 error response code indicates that a server can't serve the requested ranges. For example:

• HTTP/1.1 416 Range Not Satisfiable
• Content-Range: bytes */12777

Resolution The most common reason for a 416 error is that the file doesn't include such ranges. Browsers usually request the entire file again or abort the operation.

Error 417: Expectation failed

The server failed to meet the requirements specified in the Expect header of the client's request.

Error 429: Too many requests

The client sent too many requests in the specified amount of time, according to the server (often known as “rate-limiting”). The server might respond with information allowing the requester to retry the request after a specific period of time.

The global rate limit for the CIS API is 1200 requests per five minutes per user, and applies cumulatively regardless of whether the request is made through the dashboard, API key, or API token. If you exceed this limit, all API calls for the next five minutes are blocked, receiving an HTTP 429 response.

Some specific API calls have their own limits and are documented separately, such as Cache Purge APIs, GraphQL APIs, and rulesets APIs.

Resolution Enterprise customers can contact Support to raise the limit.

CIS generates and sends this status code when a request is being rate limited. If visitors to your site are receiving these error codes, you are able to see this in the Rate Limiting Analytics.

Error 451: Unavailable for legal reason

The server is unable to deliver the resource due to legal actions.

Typically search engines and ISPs are affected by this response code, not the origin server. The response should include an explanation in the response body with details of the legal demand.

Error 499: Client close request

Error 499 is an nginx-specific response code to indicate when the connection has been closed by the client while the server is still processing its request, which makes the server unable to send a status code back.

This error is shown in CIS logs and status code analytics for Enterprise customers.

Because the CIS partner Cloudflare is built on nginx, there is a 499 HTTP code in Cloudflare logs and analytics for connections, which are terminated before CIS has finished processing the request. It is expected behavior to see these in your logs when clients close connections.

To provide more context, a TCP connection must be established between CIS and the website's origin server before any higher protocol starts the “conversation”. To establish a connection, TCP uses a three-way handshake:

1. SYN: CIS sends three SYN packets to the origin server.
2. SYN+ACK: In response, the origin server replies with an SYN+ACK.
3. ACK: Finally, CIS sends an ACK back to the origin server.

At this point, both CIS and the origin server have received an acknowledgment of the connection, and communication is established. However, if the origin server does not send a SYN+ACK back to CIS within 15 seconds, CIS retries one more time.

Depending on the timeout value on the client side, you might see three different scenarios with their own status code generated.

• If the client has a shorter timeout (less than 30 seconds), they give up the connection, and CIS logs the 499 error.
• If the client has a higher timeout (more than 30 seconds), after the TCP connection is established, the HTTP transaction continues. In this case, CIS returns a normal status code of HTTP 200.
• If the client has a higher timeout and CIS was not able to establish the TCP handshake with the origin server, CIS returns HTTP 522.