Welcome! This site is powered by Config.com, Inc.

But what happens when something goes wrong?

Anyone can sell you server space and some basic web building tools. But what happens when something goes wrong? Config.com is there. Consider the following:

HTTP Server Status Codes (aka "Error Codes")

• 1xx series codes- A client (web browser) should not return any of these codes, as they indicate that a server is still processing the request. If it does, that could mean that the client is incompatible with HTTP versions greater than 1.0 (i.e. an HTTP/1.0 client). It could also indicate a server misconfiguration. We want to know about this! For fastest resolution of this problem, use the form below.
• 200 OK- This means that the server successfully processed the request. 2xx series codes should not be indicative of the final result; the client thus should not return these codes in the document display. If this code is unexpected, or if the code was not accompanied by the desired result, let us know below.
• 201 Created and 202 Accepted- The 201 code should be followed immediately by another code, frequently the 202 code. These indicate that the server has created the new resource [201], or that the server has accepted the request and is processing. [202] As with the 200 code, if this was not expected, please let us know.
• 203 Non-Authoritative Information- This indicates that the header metainformation was not returned by the origin server. Possible reasons for this may include a script that sends headers from another server, which is unusual but still could be considered normal. In any event, the 203 code should be handled as the 200 code is.
• 204 No Content- The server has fulfilled the request, but there is no need for the server to return an entity-body. This might accompany a change in the headers; for example, a redirect, which would be indicated by a series 3xx code. In rare instances, it could indicate a requested document is present on the server, but is null. Let us know if this somehow was the last code returned by the server, as a client should not return this code.
• 205 Reset Content- The server has fulfilled the request, and as a result the client should reset the document view. This code is used most frequently in the case of user input forms. As with other 2xx series codes, however, the client should not return a 205 code in the document display. 205 codes must not include an entity. If this somehow is not the case, let us know.
• 206 Partial Content- The server has fulfilled the partial GET request for the resource. Other header fields must accompany this code.
• 3xx Series Codes- According to the World Wide Web Consortium: "This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection." Frequently, 3xx series codes [301, 302, and 307 in particular] accompany a redirect to another resource, sometimes on another server. Generally speaking, codes of this type do not indicate anything unusual with the server. However, Config.com still is willing to assist you in diagnosing problems and unexpected results involving a 3xx series code. Let us know by using the form below.
• 400 Bad Request- This code indicates a syntax error which caused the server to not understand the request. Frequently, this is caused by bad code in a PHP, Perl, or other programming script. As with 3xx series codes, 4xx series codes do not generally indicate anything unusual with the server. Still, in keeping with offering you web hosting powered by Config.com, we can help.
• 401 Unauthorized- The credentials supplied by the user (e.g. a username and password) did not allow the user to view the requested resource. This is a common error, and often is not unexpected by the website designer, maintainer, or server administrator. We recommend that website designers and maintainers use this code to return more helpful information to the end user. Need ideas? Let us know; we can help.
• 402 Payment Required- As of the time of this writing, the 402 status code has not been implemented in the HTTP protocol, and is reserved for future use. However, we at Config.com anticipate that this code may someday be significant in certain applications. For example, subscription-based web services may someday use this code to indicate that a user's credentials reveal that although the user may normally view the requested resource (compare to code 401 above), a financial disability exists which must be resolved with the website maintainer or other department handling subscriptions. If you as a website designer would like to implement this code for your application, we can help the very moment the code is implemented in the protocol. Alternatively, we can suggest other means of accomplishing the same desired result.
• 403 Forbidden- Unlike 401 and 402 status codes, a 403 status code does not indicate any problem with the end user's credentials. Rather, access to the requested resource is prohibited to all. Possible reasons for this may include Unix permissions that are not properly set for the resource. If this is intended, and you as the website designer/maintainer do not wish the general public to ascertain the reason why the resource is forbidden, it may be a good idea to have the server send a 404 status code instead. Ask us how.
• 404 Not Found- Of course, this may be the most famous status code of them all. Config.com allows you to define custom 404 status codes, so that your users are given as much information (or as little information ;-) ) as necessary to help them understand what happened.
• 405 Method Not Allowed- The method used to generate the request (e.g. GET, POST, etc.) is not allowed for the requested resource. Following the code should be a list of allowable methods. If as a result of code, the program generating the request should be analyzed to ensure that the proper method is used.
• 406 Not Acceptable- The data the server is to return is not acceptable to the client. This happens occasionally when the client can't understand the MIME type of the requested resource residing on the server. It is generally helpful to include a message explaining the error.
• 407 Proxy Authentication Required- This is similar to a status code of 401. However, instead of authenticating directly through the HTTP server, the request is sent to a server proxy. (For example, a MySQL server to authenticate users may reside on a separate host from the web server.)
• 408 Request Timeout- The server expected a request from the client, but did not receive a fully formed request. Sometimes this occurs with data transmission problems between the client and server. Because this could conceivably indicate problems on the server side as well as the client side, we want to know! Use the form below to report this problem to us.
• 409 Conflict- This message, indicating a conflict with the state of the requested resource, is rare but most likely to occur through a PUT request. If versions are tracked, and the PUT request would conflict with an earlier request, the server may return a 409 code indicating that the request could not be completed. Let us know if you're encountering this problem.
• 410 Gone- This code indicates that the requested resource existed on the server at one time, but no longer does. Furthermore, no information is available on where that resource may now reside. We recommend using custom 404 status codes in place of the 410 code, as it's not always a good idea to reveal too much to the general public about past or present server states. Again, Config.com allows custom 404 status codes. Contact us for more info.
• 411 Length Required- As one failsafe against putting a server in a recursive loop, which might open the door to Denial Of Service attacks and other Very Bad Things, a 411 status code may be returned indicating that the server rejected the request because it could not determine the length of the headers. We can help ensure the security of your website, guiding you around such potential problems. Contact us today.
• 412 Precondition Failed- This status code indicates that the server returned a status of "false" to one or more of the preconditions sent by the client in the header metainformation. This code can then be used by the client to limit the request method to only the intended resource. (E.g. ensuring that PUT method does not adversely affect other resources.)
• 413 Request Entity Too Large- Just as headers of indefinite length can cause problems, so can headers which request too many server resources at one time. Careful analysis of the web application usually reveals ways to reduce the header for the given request, thus preventing this error. Let us know if you're encountering this error, so that we may assist you in optimizing your programming code for the server. Alternatively, we can help you obtain the proper resources for your application.
• 414 Request-URI Too Long- The World Wide Web Consortium notes that the condition indicated by this code is rare. Hypothetically, a client could be misconfigured in such a way that it converts a POST request to a GET request with a long query. Alternatively, the URI could point to itself recursively, resulting in an URI of indefinite or possibly infinite length. In any case, this is not an acceptable state. Let us know immediately so that we can help you resolve this problem.
• 415 Unsupported Media Type- This might indicate a mismatch between the requested resource and the retrieved data. For example, if a codec (i.e. an audio or video stream) is returned when the client and server expected an HTML document, this could cause a status 415. We can help resolve this problem; let us know.
• 416 Requested Range Not Satisfiable- The requested resource was out of range of the available data. One way in which this could occur is if a Perl script (especially, though other scripts can also result in this error) requests a valid file, but tries to read from beyond the EOF. Config.com is happy to assist with Perl programming issues (see below).
• 417 Expectation Failed- Either the server could not meet the conditions set by the client (i.e. "expect" statements in the header), or a proxy determined that the server is unlikely to meet those expectations.
• 5xx status codes- These generally do indicate a server error, misconfiguration, or inadequacy. Needless to say, if you encounter an error in this classification, we need to know about it as soon as possible. To quickly report this, please use the form below.