This article is covering all the server error codes details, information, and great stories in technology surrounding servers in the workplace.
We started this website sometime back about the trouble we would have working on servers, no matter what type, but mostly web servers. Considering most of us are webmasters, and encountered server error codes only a frequent basis, it made perfect sense to put together a site to track the different codes each of us received. When we slapped the website up on the Internet, it did not take long at all for many other people to find our reference site for the error codes useful.
Everyday more websites are coming online. More blogs, more SAAS services. All of this means more server errors to encounter for certain. It is funny that the further we go into the future of technology, then the further we go down the rabbit hole of bugs and errors as our technology becomes more complex.
No matter your search, we are certain you will find more information about the server error codes you are after. We have thoroughly documented each error code, and most you will find has a great story behind how we came across the server error code in the first place. Our website has been called a great server error code resource by other professionals in the industry like webmasters, server administrators, computer technicians, and network administrators.
You can start to use our error code list to your left which is sorted in numerical code order. We know just how hard server error codes can be to track down and resolve. Hopefully this article will help you on that journey of finding answers to what ails your server and gives you the information and tools you need to start finding the solution and be able to resolve the server error code you have encountered. Best of luck in your research and resolution of the server error code you are searching.
100 continue server error code is generally received when all is going well with the server request. When this happens then the client is permitted to continue on with the request being made. This 100 continue server code is a temporary response that is used to provide feedback and inform the user making the request that the transmitted packets have been received by the server and have not been denied at the moment.
In such instances, the user making the request should continue on with this request that resulted in the 100 continue server error code by sending the remaining requests if it has not been completed yet, then just ignore the 100 error code response. It is required of the server to send a final response once the initial request has been finished with no further packets sent.
A funny story on this 100 continue server error code was when we heard about this guy in a IT department for a local business kept getting this feedback in his web browser on a Windows server box, and actually thought someone was trying to hack his web server. Little did he know that this 100 server error code was business as usual and could have continued on without alerting his entire department to be aware of any abnormal activity for the “100 continue” code. True story!
The 101 switching protocol error code is one of the simplest http server error codes of them all. When you receive the 101 switching protocol code, it means the user that is making the request has asked a web server to switch the type of protocols in use and the web server has now agreed and informed the request that it will permit this.
In this case, the server is complying and understands the user’s request being asked of it, and it communicates this back via the message header field for any change in protocol the application is currently using on the connection that is established. What is known as the “Upgrade” header field communicates this in the line that immediately follows the empty line in the header before terminating the response.
So just where would you see the 101 switching protocol server message helpful? Remember, the 101 protocol is best to only be switched when it is in the best interest for the protocol to do so. As an example, when you are switching to a new HTTP version that is better and cleaner than older versions, and when you are switching in real-time, then synchronous protocol like this may be better for delivering data with features that require it to display the 101 switching protocol.
GET – the corresponding entity to a specific resource request as sent in the response.
POST – the variable containing or elaborating on the actionable result.
TRACE – the entity containing a request message when received by the source server.
HEAD – when all entity header fields contain and sync to a specific resource request and is contained in the body’s message.
Millions times millions of 200 OK server responses of a check server header are transmitted daily with every single action we request of a server through web browsers. It is hard to imagine just how many 200 OK responses from a web server could actually be served up daily with all of the web traffic that exists. While we carry on with our daily online lives posting away and submitting GET transactions, we never know all the successful requests that are posted in every second. We only worry with the server error codes don’t we?
With that said, we would to hear from you and your thoughts about 200 OK server responses. For example, how many 200 server OKs do you think the average web server gets each day. It would be fascinating to know the extent of how many of these successful events are actually recorded. We only the see the other side of a server response 200, and that is our desired response from the request we had submitted. Luckily the 200 OK is the one that works with no feedback needed!
206 partial content server error codes are received when a server has complete a partial GET inquiry for the source being requested from (known as the resource). In a 206 partial content, the request is required to include what is known as a range header area (or field) which sets the preferred Range and can also include a If-Range. An If-Range header area will then make a inquiry conditional upon completion.
A Content-Range header field (section 14.16) indicating the range included with this response, or a multipart/byte-ranges Content-Type including Content-Range fields for each part. If a Content-Length header area is present in the response, its value MUST match the actual number of OCTETs transmitted in the message-body.
ETag and/or Content-Location, if the header could be sent in a 200 response to the same request.
Expires, Cache-Control, and/or Vary, if the field-value might be different from that sent in any prior response for the same variant.
In the situation that a 206 partial content error code response results in the If-Range area, then a strong cache validation system is used. A response must not include any other forms of entry-headers, as this will prevent discrepancies between the cache bodies and the headers themselves. In any other situation, the response is required to be inclusive of all the the entry-headers that would typically return a 200 response, which means OK.
The cache area is required not to combine a 206 partial content server error code response with any other prior cached content if the ETag or Last-Modified header areas do not match exactly.
In every request, a cache that doesn’t support the If-Range and Content-Range headers is required not to cache the 206 partial content responses, also known as partial responses.
301 moved permanently is a resource that has been requested and assigned a permanent and fresh URL. Future inquires to this newly made source is best to use a returned URL. Any users that have the ability to alter links should help in this process by editing the link and attaching the proper Request-URL to the correct references returned by a server whenever at all possible. A 301 moved permanently http response of this nature has the ability to be cached unless noted elsewhere.
If a 301 moved permanently is received back in response to the request of any type of form other than HEAD or GET, then the client is required to ask the user before redirecting. The new URL is best to be permanent and then given by the location area in the next response except when the method of request used HEAD. If the request was a HEAD response, then the entity response must contain a small text note in hyper from with a properly new URL hyperlink.
This form of server status code, the 301 http, is typically received when a HEAD or GET request is not applicable, and the user is required not to redirect a request automatically unless it is permitted by the original user who submitted the request. It must be noted that redirecting automatically through the POST method once the request is received with a 301 moved permanently, then an existing HTTP/1.1 return request is thus changed to the GET request as shown above.
302 found http server code is a resource requested underneath a temporary URL since a redirect may need to be altered in certain situations. A client is recommended to continue a Request URL for any future requests and a response of this nature is only cached when indicated by the Expired field header or a Cache Control command.
Temporarily used URLs are recommended to be given by a field marked location in a received response. However if the method requested was a HEAD command, then the 302 found response shown in the web browser is best to also include a text note in hyper form along with a hyperlink pointing to a new URL.
A code like the 302 http server response is sent back to a request in a form other than HEAD or GET, then a user is required not to redirect the request automatically unless the request is validated by then original sender. A situation like this can alter the original request elements in comparison to when it was first issued. An important note from W3 is stated below.
W3 Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. 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.
304 not modified http server error code status messages are received when a requesting user has executed a condition specific request in the GET form. When this access is permitted and the original text hasn’t been altered, then the server usually responds back with the 304 not modified. This status code can not include the message body, and will have an empty line in the first part of the header field.
A 304 not modified response is required to include the date in the header field unless otherwise noted. However a clock-less source server can obey this rule, whereas clients and proxies may choose to add their own date field to a response received without this area already included.
ETag and/or Content-Location, if the header was sent in a 200 response to the same requested server.
An Expire, Cache-Control, and/or Vary area, if the field differed from what was sent in a previous request.
A GET conditional request uses a strong cache validation system, and thus a response is recommended not to include any other header entries. However if this happens and the GET conditional request uses a weak cache validation system, then a response should not include other header entries. These strong cache validation systems help prevent discrepancies between a cached body and header.
A 304 not modified http response code indicates an entry that is not currently cached. A cache is required to not acknowledge the response and repeat the request again. If the cache does use a received 304 response to then update a cache entry, then the cache is required to update the same entry and show those changes in the response back to the 304 not modified display.
307 temporary redirect server error code applies to a resource that has been requested under another URL than the source. A case like this for redirection can be changed on occasion, then a requesting client is recommended to continue to use a Request-URL in the future actions of request. A response is only saved by the Cache Control or Expires Area head field if indicated by the source.
Temporary URLs are recommended to be placed by a location area in the response. However, if a request method came in the HEAD form, then an entity response is best to also include a short text note in hyper form along with the fresh URL link. Many pre-HTTP and early 1.x version user controls to not comprehend and process the 307 temporary redirect error code. It should be acknowledged then that a note in this form is best to contain any necessary information for the end user to submit the request again if needed in a new URL.
The 307 temporary redirect server code status is acquired as the response to an original service request in a form other than the HEAD or GET fields. Also, the user control can not automatically redirect an original service request unless confirmation by the submitter is received. A situation like this can change conditions of the original request, common in exploits.
A 307 temporary redirect is generally one of two items on average. The first and most common is a technicality on the web server being requested from. Somewhere, somehow, a glitch is your your Apache, IIS, or other web platform that is causing a broken response for users to receiving the 307 temporary redirect http response in their web browser.
401 unauthorized is received when a web server that is hosting the website that the user is performing the inquiry on is sent an HTTP information stream. The receiving client which is the web browser in this case has sent the request, yet failed to provide any authorization tests put before the request in order to allow the resource attempted access on.
This 401 unauthorized error is better known as basic HTTP authorization. The form of HTTP authorization is what is expected of the client side server as placed in the authenticate portion of the header field in the WWW area.
The 401 unauthorized error code is best described as a situation when you are attempting to login to a website such as a bank account website or email website, where you have to enter a username and password to authenticate past the core landing page. Most of the time the 401 error code is displayed when these login credentials have been entered incorrectly unless otherwise customized by the website owner. This same error code can be displayed not only with incorrect credentials, but also if the user account has been suspended by the system administrator can display the 401 unauthorized.
403 forbidden http server code is received by the server as an understand request, yet is choosing to fulfill that request. Even in a case like this authorization will not suffice and the request is best not repeated. If a request being sent wasn’t a HEAD request and the web server prefers to make a public announcement why the request was not honored. The error description should provide more detail for the denial of the request and if the server prefers not to make known why the request was denied for security reasons or otherwise, then the 404 Not Found can be used in lieu of the 403 forbidden.
The 403 forbidden error code will be displayed inside a web browser the same way any web page would be displayed.
The first step in resolving a 403 forbidden error is to ensure the site domain is correct that you are entering. Make sure the domain or IP address is typed correctly in the URL bar. If the entry is correct, and the error still shows, it is best to contact the website owner to alert them of the error in case they are not aware.
403 forbidden responses are usually customized to the website it resides on, especially in the case of big corporate websites. Keep this consideration on your list as each 403 message may be different depending on each request, and on each site.
404 not found server error codes are usually customized to the website showing the 404 not found error visit the website. In fact, this is one of the most customized error codes around. Generally speaking, the 404 error is a user generated error – meaning you typed the wrong URL into the search bar, or the page you were looking for or linked from another website has been moved elsewhere on the site.
A website displaying the 404 error code assumes that the HTTP link in sent by the requesting agent is correct, but can not find the page, and thus can not display the attempted URL. When it comes to snail mail, think of this same process as a “return to sender” notice.
For the most part a customized 404 not found page is displayed in front of you on where to find the missing page used to be – or at least where you thought it used to be if it was found in error. The top level domain URL is usually the suggested starting point for most sites on a 404 error page. Sometimes the 404 can occur when a website has been moved from one web server to another also, and either corrupt DNS settings or the new location is not known are the culprits. Usually this is repaired within hours once the DNS entries get updated to the location of the website and the 404 not found will go away.
500 internal server error is possibly one of the worst error codes you can receive. Why? Because it is bland and common. It means something has went wrong somewhere, but unless you have access to the server logs, finding it is always fun. The server in question, web server that is, shows the 500 internal server error when it has ran into an unexpected variable while processing a GET request.
The 500 internal server error is so general, it is called the “Catch Everything” error for anything that goes wrong on the website server. The server is not for certain what is wrong, but just that there is a problem. The only real way of tracking down the cause of the 500 http error code is researching and sorting through the log files on the web server itself to find the error message hiding somewhere. The server should log the issue in the common folders unless you have advanced reporting modules installed from the 500 internal server error.
501 not implemented means the server will not support the ability that is required to fill the original request. This is the best fitted response when a web server is not familiar with the request method and is not capable of supporting it for any resource.
501 not implemented defines when the web server does not understand or will not support an HTTP method that it finds in the HTTP stream sent to it by the requesting agent.
OPTIONS: Displays the communication options available for a particular URL. This allows the requester to confirm the options associated with a particular resource, and assess the capabilities of the web server. No specific action involving the transfer of data is needed.
DELETE: Such as when a page on a website is deleted. Remove the data associated with the URL resource.
PUT: Put in the data for a particular URL to the new data submitted by the client.
GET: Retrieve the information identified by the URL resource.
TRACE: Run a remote, application-layer loop-back of the request message. Effectively a ‘ping’ which tests what data the Web server is receiving from the client.
HEAD: Identical to GET except that the server returns header information only, not the actual information identified by the URL resource.
CONNECT: Reserved for use with tunneling as defined only for HTTP version 1.1, and not for the earlier version of 1.0.
POST: Submit data to the Web server such as post a message to a blog or forum.
A 501 not implemented error will result if the feature in the request HTTP stream is not one of the above. A method may be still be valid, but not really supported by a server. However this usually only happens for the new methods like CONNECT when it is received by these older type of web servers to not display at 501 not implemented error.
502 bad gateway means that while performing as a proxy or gateway, the server received a non-valid response from the upstream server it accessed in the attempt to fulfill the request being made. A typical pattern of a 502 bad gateway response being displayed includes a web browser client obtains the IP address from a domain name of the website being pinged. The lookup then converts the name to the IP address itself as shown by the DNS servers.
Afterwards a IP socket connection opens up to that IP address and attempts a write of http information back through the socket. The http information stream then sends information back to the web server along with the applicable status code first determined in the protocol. Finally, the stream is extracted for relevant or needed information and the 502 bad gateway is then displayed.
We once had a Server Administrator friend of ours who claimed that much of the 502 http bad gateway problem was because of bad IP address conversation between background servers, mostly on the server that is hosting the website you are trying to access. He also recommended closing your browser and/or rebooting your computer and verifying your home router firewall is not having issues before assuming it is the website itself. The elements just mentioned can cause you to get the 502 http error also.
If those items don’t resolve it, then best is to contact your ISP as a next step and ensure there is no blockage on their end. This however can usually be ruled out if you can browse to other websites without any problem, thus narrowing a certainty that problem resides with the server hosting the website you are trying to access shows a 502 bad gateway response.
503 service unavailable means a web server that is showing this request can not handle any HTTP requests being made of it at the time because of maintenance being performed on the server, or the server has been overwhelmed with traffic and is denying requests of service. When receiving the <a href=”http://ourgreatestfear.org go to this site.com/503-service-unavailable”>503 service unavaiable error, it is assumed that it is a temporary error being displayed, and the service will be back online shortly accepting further requests. Socket errors are also coming, as webmasters can choose to block certain requests when acting on a socket method.
Generally when receiving this error, it means someone is more than likely working on the server and it is down for maintenance, or the site has received a flood of traffic that has taken it offline. Yet again, it could mean the server has erred out for whatever reason, but the likely culprit is the first two listed. Service should resume after a brief downtime, but if not, the webmaster or hosting company should be contacted to remedy the 503 service unavailable error.
504 gateway timeout is a server error code that is received when serving as a proxy or gateway server. This typically means that it does not receive adequate responses from an upstream server that was specified in the URL. Such as LDAP, FTP, HTTP, or other forms of auxiliary servers that are needed to have access to in order to finish the request being made of it.
A 504 gateway timeout is the HTTP status message which means that a web server didn’t receive a response in sufficient time from another partner server that it was trying to access, all while attempting to load the web page being requested or fill another request by a web browser.
In order to resolve a 504 gateway timeout error, then the easiest way is to try and refresh the web page in your web browser to see if it was a momentary glitch on the website you are attempting to access. Another option is to come back in a few hours and try again in case the website was simply offline at the time you were trying to access it.