Home4xx – HTTP Status CodesUncategorized4xx – HTTP Status Codes

4xx – HTTP Status Codes

4xx – Client Error

These HTTP status codes describe circumstances in which a request for a resource failed owing to incorrect syntax or for other reasons, usually due to client-side issues. Except when replying to HEAD queries, the server is required to offer a clear description of the issue and to identify whether the problem is temporary or permanent. These status codes are applicable to all request mechanisms.

400 – Bad Request

Due to improper syntax, the server is unable to process the request. Clients are cautioned not to resend the request unless all essential adjustments have been made. This circumstance shows that the web server deemed the client’s ( web browser agent) request to be improperly constructed and failed to meet the required HTTP protocol standards. The request is basically in a format that the server cannot comprehend or handle.

Example of a 400: Bad Request

A user fills out a form on a website with missing or incorrect information, such as an email address without the “@” symbol. The server responds with a 400 status code, indicating that the request was invalid and should be modified before resubmitting.

401 – Unauthorized

This response code indicates that the responding server requires user authentication or that the credentials provided in the request were denied. When you get a 401 error just after inputting your credentials, it usually signifies that either the username, password, or both were incorrect. This error essentially indicates a problem with the authentication procedure, suggesting that access cannot be allowed until valid credentials are checked.

Example of a 401: Unauthorized

A user attempts to access a restricted resource, such as a user profile page, without first checking in. The server returns a 401 status code and requests authentication credentials.

402 – Payment Required

This status code is held in reserve for future usage, primarily in digital payment systems. The 402 code was originally intended to function within such systems, however this application has yet to be realised. For the time being, it serves as a placeholder for future scenarios in which a payment requirement may be incorporated into the HTTP protocol.

Example of a 402: Payment Required:

(Note: For the time being, this status code is rarely utilised and is mostly reserved for future usage.)

403 – Forbidden

This status code indicates that the server received and comprehended the request but opted not to process it. Unlike other permission issues, even correct user credentials would not provide access in this scenario. The server’s denial to perform the request is not due to authentication concerns, but rather to the server being designed to deny access to this specific request regardless of the requester’s identity or permissions.

Example of a 403: Forbidden 

Without necessary rights, a user attempts to visit an admin-only page. The server recognises the request but refuses to authorise it, sending a 403 error code.

404 – File Not Found

This error happens when the server can process the HTTP request from the client (such as a web browser), but cannot find the file or resource indicated in the requested URL. The server’s answer does not indicate whether the file’s absence is temporary or permanent. It’s the equivalent of the postal service returning a mail with an “address unknown” note.

A 404 error should be distinguished from difficulties such as “server not found,” which occur when there is no connection to the server at all.

When you enter URLs like www.my_website.com, a 404 error may occur if the request is routed to the incorrect server, maybe owing to faulty DNS entries. If the entire website is down, a 404 error is possible. If it’s a DNS problem, the site should be available after the global DNS records are changed.

A 404 error usually indicates a broken link, especially for lower-level URLs.

Example of a 404: File Not Found 

A user clicks on a broken link or enters an incorrect URL, such as www.example.com/nonexistentpage, resulting in a 404 error because the server cannot locate the requested resource.

405 – Method Not Allowed

This error code is returned when the HTTP method used in the request is not supported by the server for the requested resource. The HTTP protocol defines a number of methods for interacting with web resources, and servers can be configured to allow or restrict specific methods.

A 405 error happens when a client attempts to submit a form using the POST method but the server is configured to deny POST requests for that specific URL. It may also show when a web server is not configured to handle user requests using a specific technique.

Such problems, which result in a 405 error, are often recorded in the server’s logs. This helps your hosting provider or server administrator to troubleshoot and explain things more easily.

Example of a 405 : Method Not Allowed 

A web form can only accept GET requests, yet a user attempts to submit it with a POST request. The server responds with a 405 status code, indicating that the requested method is not available.

406 – Not Acceptable

This status code is given when the client defines the type of data it expects in response and the web server recognises that it is unable to deliver that content. When a client sends a request, the ‘Accept’ headers can be used to specify the formats it is happy to receive. If the server’s available response formats do not match these settings, a 406 error is returned.

When working with web browsers, this circumstance is very uncommon because they are often designed to accept a wide range of data types from the server. Non-browser clients, on the other hand, may have more stringent requirements, as specified by their Accept headers. In such circumstances, checking these headers as well as the server’s accessible data types can assist in identifying the mismatch that is causing the 406 error.

Example of a 406: Not Acceptable 

A client wants an XML-only resource, while the server can only supply JSON. The server returns a 406 error code because it cannot meet the Accept header requirements.

407 – Proxy Authentication Required

This status code is identical to 401 (Unauthorized), however it applies only to proxy servers. When a client, such as a web browser or a monitoring agent, delivers a valid request but needs to authenticate with a proxy server before accessing the requested resource, a 407 error occurs. Essentially, this means that before the request can be processed, the user must check in to the proxy server, generally by entering a user ID and password. The 407 answer indicates that proxy authentication is required before visiting the desired URL.

Example of 407: Proxy Authentication Required 

A user attempts to access a resource that requires authentication via a proxy. The server responds with a 407 status code and requests proxy login credentials.

408 – Request Timeout

When a client fails to finish a request within the timescale specified by the server, this error code is returned. In certain circumstances, the server times out and responds with a 408 code. Clients may retry the same request at a later time without modification.

If 408 errors occur frequently, it is recommended that you investigate the workload on your web server at such times to uncover potential causes. Persistent 408 errors may indicate server-side problems such as high traffic or processing delays. Alternatively, these errors could be the consequence of connectivity issues, indicating that the problem is with the network rather than the server.

Example of a 408: Request Timeout 

A client initiates a request but fails to complete it in a timely manner, possibly due to a poor network. The server timed out and returned a 408 error code.

409 – Conflict

When the web server recognises the client’s request as valid but is unable to fulfil it owing to a conflict with the existing state of the requested resource, this status code is returned. The server returns a 409 error, frequently with details in the response body to assist the user in understanding and resolving the underlying problem.

These issues are typically unrelated to regular web server authority or security concerns. Instead, they frequently include unique concerns within the programme, such as multiple users updating the same data at the same time. These forms of conflicts are exclusive to the logic and operations of the application, rather than the HTTP protocol itself.

Example of a 409: Conflict 

A user attempts to update a resource, such as a blog post, that has been modified by another user during the editing process. The server returns a 409 status code, indicating a conflict in the resource’s present state.

410 – Gone

This status code is used when a previously available server resource is no longer available and there are no plans to make it available again in the future. Furthermore, no forwarding address is supplied for the resource. In such circumstances, the server returns a 410 error, indicating that the resource has been permanently removed or is no longer available. It’s similar to a 404 – File Not Found problem, except that a 410 status plainly denotes a permanent issue, as opposed to the potentially transient nature of a 404 mistake.

Example of a 410 – Gone 

A user attempts to access a resource that was once available on the server but has since been permanently removed, with no forwarding address. The server responds with a 410 status code.

411 – Length Required

This status code is given when the server refuses to perform a request because it lacks the specified content-length. Essentially, the server expects the request to include a ‘Content-Length’ header field that indicates the message body size. As a result of this error, the client should resubmit the request with a valid content-length header that appropriately represents the length of the request’s message body. This ensures that the server has all of the information it needs to handle and process the request correctly.

Example of 411 – Length Required 

A client sends a POST request without the required Content-Length header. The server answers with a 411 status code, requesting the length of the content.

412 – Precondition Failed

When the server reviews a request and discovers that one or more preconditions stated in the request-header fields are not met, it returns this error code. It essentially allows the client to specify certain preconditions about the metadata (information contained in the header fields) of the resource. These preconditions are used to ensure that the desired action is only done if particular criteria are met, preventing the method from being applied to an unwanted resource. If these criteria are not met, the server returns a 412 status code, indicating that the precondition(s) failed.

Example of a  412: Precondition Failed 

If-Match headers are included in a request to update a resource by a client, but the condition fails. As the precondition is not met, the server returns a 412 status.

413 – Request Entity Too Large

When this status code is sent to the server it rejects processing the request because the formatting of the request entity is too large for the server to handle. In reaction, the server may even terminate the connection in order to prevent the client from completing the request. The ‘too large’ barrier varies and is frequently specified by the server’s capabilities and configuration. A request involving the upload of a particularly big file, for example (using the HTTP PUT method), may exceed the server’s maximum allowable file size limit, resulting in this error. The 413 error effectively conveys that the data size in the client’s request exceeds the restrictions set by the server.

Example of a 413: Request Entity Too Large 

A user attempts to upload a file that is larger than the server’s size restrictions. The server responds with a 413 status code, indicating that the entity is too large.

414 – Request-URL Too Long

The web server rejects performing the request because the Request-URL is too long for the server to interpret, this status code is returned. This unusual situation may occur if a client structures a POST request incorrectly with extensive query information, becomes trapped in a cycle of URL redirection (where a redirected URL leads back to itself), or if a malicious client attempts to exploit security vulnerabilities in servers that use fixed-length buffers to process the Request-URL.

URL lengths are often limited by web servers, often up to 2048 or 4096 characters. If a legitimately long URL repeatedly results in a 414 error, the server’s configuration may need to be modified to handle longer URLs. This error primarily serves as a protection against problems caused by parsing excessively long URLs, which could be problematic for server operations.

Example of a 414: Request-URL Too Long 

A client creates an excessively long URL due to a faulty script. The server returns a 414 status code because it cannot parse such large URLs.

415 – Unsupported Media Type

When the server is unable to perform a request because the format of the request’s entity is incompatible with the requested resource or method, this status code is returned. It signifies that the server does not support the media type of the data given by the client in the request body for the specific resource or activity requested. This could happen if the client tries to upload a file in a format that the server does not support for processing or storage. The server rejects the request in such circumstances, signalling that the client must change the format of the given data to one that is compliant with the server’s capabilities or requirements for that specific resource or method.

Example of a 415: Unsupported Media Type 

A client tries to upload a file in a format that the server does not support, such as uploading an.exe file to a server that only accepts pictures. The server responds with a 415 status code.

416 – Requested Range Not Satisfiable

When a client’s request includes a ‘Range’ header field indicating a portion of a resource, but none of the supplied ranges can be satisfied by the server, this status code is returned. This is common when the range values do not correspond to the current size or extent of the targeted resource and the request lacks a ‘If-Range’ header field.

For example, if a client requests a byte range of 500 to 1500 on a resource with a capacity of only 1000 bytes, the server will be unable to fulfil the request since the requested range exceeds the resource’s boundaries. The server responds with a 416 status code in such cases, indicating that the requested range is not available within the scope of the existing resource. This code aids in the efficient management of data transfer, particularly in cases involving partial or segmented data retrieval.

Example of a 416: Requested Range Not Satisfiable 

A client requests a file’s byte range that is larger than its real size. The server returns a 416 status code because it cannot satisfy the required range.

417 – Expectation Failed

This status code is sent when a web server is unable to meet the conditions stated in the client’s request’s ‘Expect’ request-header field. The ‘Expect’ header allows clients to specify certain expectations that the server must meet in order for the request to be executed correctly. A 417 error is given if the server, or a proxy server operating on its behalf, determines that these expectations cannot be met or that the next server in the chain (next-hop server) unequivocally cannot perform the request.

This status code informs the client that the server is unable to meet the requirements specified in the ‘Expect’ header, indicating the need for changes to the request parameters or expectations. It aids in the effective communication and processing of requests between clients and servers, particularly when certain conditions must be met before a request can be completed correctly.

Example of a 417 – Expectation Failed 

An Expect header containing constraints that the server cannot meet is included by the client. The server responds with a 417 status code, indicating that it is unable to meet the expectation.

Leave a Reply

Your email address will not be published. Required fields are marked *