HTTP Status Codes: Every Possible Code Listed

by Frank Moraes

Last updated: August 6, 2020

Disclosure: Your support helps keep the site running! We earn a referral fee for some of the services we recommend on this page. Learn more

HTTP Status Code Basics

Most people don’t think too hard about what actually happens when they navigate to a web page. They just open their browser, click something, and there it is on my screen!

Looking for specific code? Have a look at the table of contents on the right!

We prefer not to think about the complex dance of requests and responses happening between our computer’s web browser and a server far away, in a data center, unseen (usually) even by the website’s system administrator and IT staff.

But then, every now and then, we run into an error. We get a clever 404 Not Found page with a funny picture it. Or we get a blank page with a note from our own browser telling us about some unknown 501 Error.

As a casual website visitor, this is merely annoying. We usually try again — refresh, go back, click again. Sometimes it works — we call that a glitch and promptly forget about it. Sometimes it doesn’t work — we call that “a bad website” and usually promptly forget about that, too.

But if you’re actually running a website — that changes everything. The HTTP errors aren’t annoying. They are maddening. They are embarrassing.

If you’re especially tech savvy, or if you have a good IT team, this may not be that big a deal. Most problems like that are easy to fix. But if you’re a small business owner, running your own website, HTTP status and error codes can drive you crazy.

How do you fix HTTP errors? How do you do avoid HTTP errors? What do all these HTTP status codes mean, even?

That’s what this guide covers, along with information about:

good HTTP status codes (the ones you usually don’t see)
useful HTTP status codes
what type of redirects you should be using (and why).

But first, in order to understand HTTP status codes, you have to understand how HTTP works in the first place.

HTTP Requests and Responses

HTTP stands for “HyperText Transfer Protocol.”

What’s a Protocol?

When you board a Naval ship, there’s a certain way of doing things. First you salute the flag, then you salute the officer on duty, then you ask for permission to board.

That’s a protocol.

A protocol is a set of rules for a certain type of interaction.

Sometimes a protocol is very rigid and defined:

To board a ship:
- Salute flag
- Salute officer on duty
- Ask for permission to board.

Sometimes protocols are a little looser and unwritten, but still well-known:

When your birthday cake arrives:
- Wait for everyone to finish singing
- Make a wish
- Blow out the candles, preferably in one breath.

Computer interactions are all about protocols. When two computers (or a network of computers) talk to each other, they have to have a set of well-defined rules for communicating.

The rules for how your local computer’s web browser communicates with the web server that hosts the site you are trying to look at is HTTP (HyperText Transfer Protocol).

Why Are We Transferring HyperText?

Originally, web pages were primarily documents. A “web page” was thought of as an actual “page.” A site was a collection of documents. The main page for a site was an “index” of the documents available.

What type of documents? Hypertext documents.

Hypertext just means that the documents link to each other with “hyperlinks.” Today we just call them plain-old “links” — they’re so ordinary now that we don’t call them “hyper” anymore.

Clickable “hyper” links in text — that idea, which is so commonplace now, was so revolutionary when the inernet was first being created that everything was named after it.

The language for authoring these documents? Hypertext Markup Language (HTML). And the protocol for requesting and receiving these documents? HTTP.

So HTTP Is…

HTTP is the set of rules and procedures for how a web browser (or other “client”) requests resources from another computer (the “server”), and how that other computer responds to those requests.

HTTP Request

So, when you type an address, click on a link, or otherwise open a web page, your browser is sending a request to some other server.

The target of the request is defined by the URL and the DNS system. The DNS system is a subject for another day, but basically — the DNS is an address book that matches domain names to specific computer IP addresses.

The request’s target is defined by the domain name, and the entire URL is the most important part of the request — everything after the domain name tells the server the specific resource being requested. The request also contains other information like:

The request type. The two most common are:
- GET — “Please send me this resource.”
- POST — “Here is some data to process.”
Header Fields — Optional meta data fields used to tell the server about the client (what type of browser, for example).
Body — The data sent by client (for use with POST).

The server gets this request and (after some processing) sends a response.

HTTP Response

The very first line of a response is the HTTP Status.

The status line has two parts, a number code (like 200) and a text explanation (like Success).

When everything works fine, you get the 200: Success status (which you as a human user never see), then some header data (which you also don’t see), and then the resource you requested (which is what you do see).

The resource might be a whole web page, an image, a video, a sound file. It might also be something you don’t see, like a JavaScript file or a stylesheet.

When things don’t work out so well, you might see a message about the Status. Usually that happens when you get something like a 404 or 501 code. Those are error codes. Something went wrong.

Responses with 404 or 501 error codes don’t come back with the resource you requested. Sometimes they come back with a different resource (like the clever 404 page). Sometimes there’s no resource at all (that’s when you get the browser’s blank page and default error message).

There are also status codes that tell the browser to look somewhere else, like the 301 redirect. These responses also don’t come the requested resource.

Instead, the header data tells the browser to make a new request with some other URL. You usually don’t notice when that happens, because your browser just does what it’s told and makes the second request.

Then it shows you the resource from the second response, without telling you that anything happened. Redirect response codes usually don’t matter to end users, but they should matter a lot to website administrators.

Status Code Classes

You’ve probably noticed that all the status codes are three-digit numbers. Did you notice that the first digit is always between 1 and 5?

Status codes are grouped into five “classes” of codes. The 404: Not Found error is part of the 400 (or, sometimes, 4xx) class of status codes. Each class encompasses a particular range of issues or states.

1xx — Informational — These are provisional responses intended to be used while the server continues to process the request. They are seldom used.
2xx — Success — Codes used when things work as they are supposed to. Different success codes are returned based on what, specifically, the request was attempting to do.
3xx — Redirection — Codes used to tell the client to look for the requested resource somewhere else.
4xx — Client Error — These codes tell the client that it did something wrong.
5xx — Server Error — Code for when something on the server isn’t working as expected.

We’ll cover the specific codes from each class in more depth in their own sections.

Dealing With HTTP Status (and Error) Codes

This guide covers all the possible HTTP status and HTTP error codes — from the common to the never-used. We’ll explain what each code means, why they are being generated, when the code might be a problem, and how to deal with the problems.

HTTP Status Code 1xx — Informational

Knowledge is power. Information is liberating.
—Kofi Annan

HTTP Status codes in the 1xx class are intended to be provisional, sent by the server before a full and completed second response is sent.

They were introduced in HTTP/1.1, so early browsers implementing HTTP/1.0 cannot handle them, and servers should not end 1xx codes in those cases.

HTTP 100 Continue

Typically a request-response sequence is straightforward. One single request is made, received, and responded to.

But sometimes a request needs to be broken up into parts. This might occur if the request is too big. It might occur if the requester needs to check if the header is formatted properly, or if the server is actually ready to receive the request.

In these cases, the client (browser) might send the initial request with a header that includes Expect: 100-continue.

When that occurs, the server will receive the initial request and — if everything is okay — respond with the 100: Continue status. This signals the client to complete the request.

If everything doesn’t work out ok, the server will send back a 417 Expectation Failed.

HTTP 101 Switching Protocols

A client can ask a server to switch protocols, for example from HTTP/1.1 to HTTP/2.0.

If the server is willing to comply with that request, it will send back the response 101: Switching Protocols, along with header data that includes the name of the new protocol being used.

HTTP 102 Processing

This code is only used with WebDAV, which is an extension of HTTP that provides file manipulation ability, somewhat similar to FTP (though very different in actual implementation).

A WebDAV request might include a lot of sub-requests. The 102: Processing status lets the client know that the server received the request and is working on it, but still has work to do. This keeps the client from assuming the request was lost and timing out.

HTTP Status Code 2xx — Success

All you need in this life is ignorance and confidence, and then success is sure.
—Mark Twain

HTTP Status codes in the 2xx class are intended to be used when a request has completed as intended.

Many of these codes are never, or rarely, actually used, or even implemented.

HTTP 200 OK

This is the standard response for successful requests — it’s the status code you usually want and expect.

When the request is GET (asking for a resource), the response will include the resource. When the request is a POST (or other type), the response will contain a resource which describes or contains the result of the action.

HTTP 201 Created

Some requests are intended to create a new resource. When these complete successfully, the 201 status is sent to indicate that the new resource has been created. This is usually used in conjunction with the PUT request type.

HTTP 202 Accepted

The request has been accepted, but not acted upon. The request may or may not be acted upon.

HTTP 203 Non-Authoritative Information

The response contains the requested resource, but the resource may have been obtained from another source, and therefore might be unreliable — the server is not vouching for the validity or authenticity of the resource.

HTTP 204 No Content

This is sent when the server successfully processed the request, but doesn’t need to return any content. Most often, this occurs as the result of a DELETE request.

When a 204 request is sent, the user agent (the client or web browser) is specifically not supposed to change its view.

For example, if the request was sent via a form on a page, the response should not cause the form to be refreshed or for the browser to visit another page — there is not new content in the request to replace the existing content in the user’s view.

HTTP 205 Reset Content

The 205 response is similar to a 204, but the user agent is supposed to refresh their view back the the default state of the current document.

HTTP 206 Partial Content

This is used when the server is only sending a portion of the requested resource, because the user requested to only receive a portion of the resource.

This occurs when a resource is large enough, or the connection unreliable enough, that the user agent wants to split the resource into a series of “chunked” requests, as illustratred:

Client: Give me the first 1/4.
- Server: 206 Partial Content
Client: Give me the second
1/4.
- Server: 206 Partial Content.
And so on…
- …and so forth.

These partial requests are made by the client using the range header. They might occur one after another (to guard against download failure), or all at once in multiple threads (to speed up download).

HTTP 207 Multi-Status

Like 103, this is only used with WebDAV.

A WebDAV request can have multiple sub requests, each one having its own status and response. The 207 status indicates that the body of the response will include an XML document detailing the status and responses of each sub-request.

HTTP 208 Already Reported

Another WebDAV-only status code. This one means that the members of a DAV binding have already been enumerated in a previous reply to the current request, and are not being included again.

HTTP 226 IM Used

The server has fulfilled a request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.

HTTP Status Code 3xx — Redirection

Whenever you give up something, you must replace it with something.
—Lou Holtz

Statuses in the 3xx class are sent when additional action is required on the part of the client in order to complete the request. This is most commonly used in redirecting one URL to another, though not always.

In the case of GET requests, the browser will generally carry out the second request without any input or additional interaction from the user. In other cases, additional user intervention is required.

To avoid infinite redirection loops, browsers typically will not follow more than five successive redirection of the same request.

HTTP 300 Multiple Choices

The 300 status is returned by browsers when the request results in multiple options for the resource. In theory, this could be use to present different file format options, different media presentations of the same content, or even word sense disambiguation.

The 300 Multiple Choice status has a lot of potential, but is not often used.

HTTP 301 Moved Permanently

This status indicates that the resource has changed URL permanently.

Search engines update their index based on this, usually assigning any ranking from the original URL to the new URL.

Browsers and other types of clients often cache the new URL and automatically follow the redirect URL without directly checking the original for subsequent requests, even if the original URL is manually supplied. Saved bookmarks are also typically updated.

Generally, if you are setting up redirects because of a change in domain name of URL structure, you should use 301: Moved Permanently redirects.

These can be set up in the .htaccess or httpd.conf file on your server, or often in your content management system. (For example, there are several WordPress plugins for managing 301 redirects.)

When a website is redesigned and a URL structure changed, it is very important to set up a 301 redirect for every URL from the original site. Failure to do so will cause broken links and disappointed visitors.

HTTP 302 Found

The 302 status code is commonly used for temporary redirects. Industry practice with 301 redirects has varied from the original specification, and the specification has evolved to meet industry practice.

Originally, the specification stated that a 302 status should cause the browser to make a second, identical request to the new URL. However, many first-generation web browsers implemented it in such a way that POST requests were re-written as GET requests.

To attempt to clarify the situation, the updated specification HTTP/1.1 added two additional status codes, 303 and 307.

302 Found was supposed to mimic the “switch to GET” behavior that had been implemented, while 307 Temporary Redirect was intended to replace the original 302 expected behavior.

However, most servers and web frameworks simply continued to use 302 for backwards compatibility with browsers that don’t implement the newer standards.

Later HTTP specifications acquiesced to standard practice, allowing browsers to rewrite POST requests to GET requests.

The consequence of all this is that if you are using a 302 redirect on a URL that was supposed to accept POST data, that data will likely not be included in the second request.

For this reason, 302 should only be used on URLs that accept POST data (web forms) if the server can actually accept the submitted data at the original URL, and use the redirect to deliver a page after the data has been accepted.

All of this, in practice, makes the 303 redundant.

Generally, a 302 redirect should not be used

HTTP 303 See Other

In practice, this is identical to a 302 status. It means that the response or resource can be found at another URL using the GET method. When received in response to a POST request, the browser should assume that the data has been received.

HTTP 304 Not Modified

Web browsers can send a request with a header that asks if a resource has been modified since a particular data and time. This is done if the browser has already downloaded the resource previously and saved it.

If it has been modified since that time, the server will respond with the resource and a 200 Success status.

If, however, the resource has not been modified, the server will send the status 304 Not Modified and not also sent the resource. The browser should then serve the saved version of the resource, since it hasn’t changed.

HTTP 305 Use Proxy

The requested resource is only available through a proxy. The address of the proxy is provided in the response. The web browser is expected to retry the request through the proxy. Not all clients implement this according to the standard, because of security reasons.

HTTP 306 Switch Proxy

The 306 status originally meant “Subsequent requests should use the specified proxy.” It is not longer in use.

HTTP 307 Temporary Redirect

This status was created to replicate the original intention of the 302 status (see above).

The 307: Temporary Redirect status means that the request should be repeated this time with another URL, but that in the future, however, requests should still use the original URL.

In contrast to how 302 has historically been implemented by clients, the request method should not be changed when sending the second request. For instance, a POST request should be repeated using another POST request, and with all original POST data included.

HTTP 308 Permanent Redirect

The current request should be repeated using another URL, and all future requests should be sent to that URL as well.

Like 307 and 302, this status duplicates the functionality specified in the original specification of 301. With 308, though, (as with 307) the second request should be identical to the original request — using the same method and containing the same data.

HTTP 308 Resume Incomplete

This status code was created and is used by Google. It is a part of the Resumable HTTP Requests Proposal, and is used to resume aborted PUT or POST requests.

HTTP Status Code 4xx — Client Error

Anyone can make mistakes, but only an idiot persists in error.
—Marcus Tullius Cicero

Of the five classes of HTTP status codes, only two of them are really “Error Codes,” the 4xx and 5xx classes.

The 4xx series of HTTP errors is intended to be used when the error seems to be coming from the client — that is, there is something wrong with the request.

Along with the error status and other header information, servers often provide a complete response (called an “entity” instead of “resource,” but otherwise the same) which is supposed to be displayed to the user.

This is intended to provide the user with a way to fix whatever the client error was. The most commonly seen form of these entities is the 404 page, discussed below.

HTTP 400 Bad Request

This is a generic response to a request with some problem. The problem could be malformed syntax, invalid formatting, or deceptive request routing. Servers will often provide additional information about what specifically went wrong with the request.

HTTP 401 Unauthorized

This is used when the resource is restricted to certain authenticated users. The status means that wither there has been no authentication, or that authentication has failed. According to the standard, a response with this code is supposed to include a means of authenticating.

HTTP 402 Payment Required

Not commonly used, as the specification does not provide enough information for a current implementation (it has been named and reserved for future use, but a full spec has not been adopted).

The intention is to use this code as part of some type of digital cash or micropayment system.

YouTube uses this status if they receive too many requests from a single IP address. The response requires a CAPTCHA to verify the user is a human.

HTTP 403 Forbidden

Similar to 401, this means that the request was valid, but the server will not respond to it because the user does not have permission to view the resource. Unlike a 401: Unauthorized error, authenticating will make no difference.

HTTP 404 Not Found

This is the most commonly seen 4xx class error, and maybe the most commonly noticed HTTP status for the average user.

404 is returned if the request is valid, but the requested resource simply cannot be found on the server.

Most web frameworks give the website administrator the ability to create a “404 Page.” This is a page that the user see when a 404 error occurs.

Typically, this informs the user of the problem, apologizes for the inconvenience, and provides alternate ways of finding the content the user is looking for, such as search.

Some websites will look at any keywords in the request URL and try to determine what page or resource the user might have been looking for, and provide one or more options for alternate pages.

Even though 4xx errors are technically “Client Errors,” the 404 error often is a result of dead links — URLs that previously had content but which have now changed.

For this reason, having to deliver a 404 page can be a little embarrassing for websites, as it often means a failure to provide proper URL redirection. The implication isn’t “you messed up your request,” but rather “we lost the thing you are looking for.”

Because of this, it is very common for websites to turn their 404 Pages into a place for humor.

HTTP 405 Method Not Allowed

This is used when the request is well-formed and the resource it asks for does exist, but the request method (such as GET or POST) is not appropriate to the resource.

For example, a URL that received form data should be accessed with a POST request. A GET request may result in a 405: Method Not Allowed response. Using PUT on a read-only resource may also cause such a response.

HTTP 406 Not Acceptable

Requests can, and often do, specify the type of content they are looking for, using MIME types.

If the requested resource is of a type that does not match the type(s) listed in the Accept header of the request, the server will return the 406: Not Acceptable error.

HTTP 407 Proxy Authentication Required

Before being given access to the requested resource, the client must first authenticate itself with the proxy specified in the response.

HTTP 408 Request Timeout

This error happens when the server times out while waiting for the request.

From the specification:

The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.

HTTP 409 Conflict

Indicates that the request could not be processed because it conflicts with itself. This may occur, for example, in the case of multiple updates that cause edit conflicts with each other.

HTTP 410 Gone

This error is similar to the 404 error, but is intended to indicate the requested resource has been intentionally removed and will no longer be available at any URL.

Clients should reacts to this response by purging the resource — bookmarks should be deleted and search engines should remove the resource from their indices.

Most use cases do not require this, and the 404 is usually a more appropriate error.

HTTP 411 Length Required

The requested resource requires that requests specify their length, and the request did not do so.

HTTP 412 Precondition Failed

The requester placed preconditions or requirements into the request’s header, and the server is unable to meet one or more of those requirements.

HTTP 413 Request Entity Too Large

The request is larger than the server is able to process.

HTTP 414 Request-URI Too Long

The URI (URL) provided was too long for the server to process.

This is often cause when an inappropriate amount of data is being conveyed within the URL as a query string in a GET request. The usual remedy is to convert the request to a POST and place the data into the body of the request.

HTTP 415 Unsupported Media Type

This generally used for file uploads, when the request entity (the file being uploaded) is of a type not supported by the server.

HTTP 416 Requested Range Not Satisfiable

This is returned when the request is asking for a portion of the file, using the range header, but the requested portion does not exist. For example, if the request asks for a part of the file which is beyond the end of the file.

HTTP 417 Expectation Failed

This status is returned by a server if it cannot meet the expectation set by the expect header in the request.

The expect header is most commonly used to ask the server for a 100 Continue status.

HTTP 418 I’m a teapot

This error code is returned by internet connected teapots, in the event they are sent a request for coffee.

HTTP 419 Authentication Timeout

This is not actually a part of the HHTP standard, but some clients and servers use it. It is returned when a request that requires an authenticated user is sent by a requester whose authentication has expired.

HTTP 420 Method Failure (Spring Framework)

Not part of the HTTP standard, but defined by Spring in their web framework, for use when a method failed. It is deprecated.

HTTP 420 Enhance Your Calm (Twitter)

Not part of the HTTP standard, but introduced by Twitter. This was used by Version 1 of their API when requests from a particular client were being rate limited.

The more standard status for such a situation is 429: Too many Requests.

HTTP 421 Misdirected Request

This status was introduced in HTTP/2. It is used when the request was directed at a server that is not currently able to produce a response.

HTTP 422 Unprocessable Entity

This is related to the WedDAV extension. It is returned when semantic errors make the request unprocessable.

HTTP 423 Locked

Used with WedDAV. It means that the requested resource is locked.

HTTP 424 Failed Dependency

Used with WebDav. The request failed because a previous request, which the current request is dependent on, failed.

HTTP 426 Upgrade Required

The client should switch to a different protocol, as specified in the upgrade header.

HTTP 428 Precondition Required

This is used when the server requires that the request be conditional.

For example, the server may require that the request contain a condition that the request should only be processed if the resource has not been updated since a particular date and time. If no condition is specified, the request fails and this status is returned.

According to the specification, this status was intended to prevent “the ‘lost update’ problem, where a client GETs a resource’s state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.”

HTTP 429 Too Many Requests

The client (usually as defined by IP Address) has sent too many requests within a specified period.

HTTP 431 Request Header Fields Too Large

This is returned when a single header field, or all of them collectively, is too large for the server to process.

Not part of the standard, but used by Microsoft. Indicates that the session has expired.

HTTP 444 No Response (Nginx)

Not part of the standard. Not actually a response status as used.

This was introduced by Nginx for their server logs, to indicate when the server simply did not send a response and closed the connection, usually in the event of a suspected malware attack.

HTTP 449 Retry With (Microsoft)

Not part of the standard, but used by Microsoft.

The request should be retried after performing the action described in the response.

HTTP 450 Blocked by Windows Parental Controls (Microsoft)

Not part of the standard, but used by Microsoft.

This error is given when Windows Parental Controls are turned on and are blocking access to the given webpage. The error originates from the WPC application, not the server.

HTTP 451 Unavailable For Legal Reasons (Draft)

This status is not part of the standard yet, but is available in draft form.

The intended use is for when a resource cannot be provided due to censorship or other legal reasons. The code number is a reference to the book Farenheit 451.

HTTP 451 Redirect (Microsoft)

Not part of the standard, but used by Microsoft. Occurs in Exchange ActiveSync if there either is a more efficient server to use or the server cannot access the users’ mailbox.

HTTP 494 Request Header Too Large (Nginx)

Not part of the standard, but was used by Nginx. Now deprecated.

This had the same meaning as 431, but was introduced before that status was a part of the HTTP standard.

HTTP 495 Cert Error (Nginx)

Not part of the standard. Not actually a response status as used, but appears in Nginx logs when an SSL client certificate error occurs.

HTTP 496 No Cert (Nginx)

Not part of the standard. Not actually a response status as used, but appears in Nginx logs when the client didn’t provide certificate.

HTTP 497 HTTP to HTTPS (Nginx)

Not part of the standard. Not actually a response status as used, but appears in Nginx logs when plain HTTP requests are sent to HTTPS port.

HTTP 498 Token Expired/Invalid (Esri)

Returned by ArcGIS for Server. A code of 498 indicates an expired or otherwise invalid token.

HTTP 499 Client Closed Request (Nginx)

Not part of the standard. Not actually a response status as used, but appears in Nginx logs when the connection has been closed by the client while the server is still processing its request, making server unable to send a status code back.

HTTP 499 Token Required (Esri)

Returned by ArcGIS for Server. A code of 499 indicates that a token is required (if no token was submitted).

HTTP Status Code 5xx — Server Error

I am indeed amazed when I consider how weak my mind is and how prone to error.
—Rene Descartes

Along with the 4xx series, the 5xx class of HTTP status codes are error codes, issued when something goes wrong. The 5xx error codes are Server Error codes, meaning that they are returned when the problem is on the server, rather than with the client.

Whenever possible, the server should return a response entity which describes the error to the client. User agents (web browsers) should show this information to the user.

HTTP 500 Internal Server Error

This is the most generic Server Error, and is issued by web servers when something indeterminate went wrong.

Generally, any change to a website or server configuration should be followed by thorough testing to make sure that a 500: Internal Server Error is not produced.

When a 500 error is produced, looking at the server logs can often help determined where the error is coming from. It can often be as simple as typographical errors in the .htaccess file.

HTTP 501 Not Implemented

This is returned when the HTTP request method (such as PUT or DELETE), the API method in some cases, has not yet been implemented. This is used for web service APIs. Usually, the implication of a 501 error is that the request method is planned for future implementation.

HTTP 502 Bad Gateway

This occurs when the server is acting as a proxy or gateway, and receives an invalid response from the upstream server.

HTTP 503 Service Unavailable

The server is currently unavailable. For example, because it is overloaded or down for maintenance.

The implication of a 503 error is that the outage is temporary.

HTTP 504 Gateway Timeout

This error is returned when the server was acting as a proxy or gateway, and does not receive a response from the upstream server within the time alloted.

HTTP 505 HTTP Version Not Supported

This error means that the server does not support the HTTP protocol version used in the request.

HTTP 506 Variant Also Negotiates

To understand the 506 error, you have to understand transparent content negotiation.

With content negotiation, a single URL can deliver the same resource or information in multiple formats. For example, the same image might be encoded as a JPEG and as a GIF.

The 506 error occurs when this content negotiation causes a loop. For example: The requested resource A has two variations — B and C. Both of these have A as a variant.

To put that in more technical language, the specification describes the 506 error with:

Transparent content negotiation for the request results in a circular reference.

HTTP 507 Insufficient Storage (WebDAV; RFC 4918)

This status is used the WebDAV protocol. It is returned when the server is unable to store the representation needed to complete the request.

HTTP 508 Loop Detected

The server encountered an infinite loop while attempting to serve the requested resource.

HTTP 509 Bandwidth Limit Exceeded (Apache)

Not part of the HTTP standard, but introduced and used by Apache. It is issued when the servers bandwidth limits have been exceeded.

HTTP 510 Not Extended

This error means that further extensions to the request are required for the server to fulfill it.

HTTP 511 Network Authentication Required

The 511 error is returned when the client needs to authenticate to gain network access.

This status is intended for use when intercepting proxies used to control access to the network — that is “Captive Portals” used to require login or Terms of Service agreement before granting access to the internet via a WiFi portal.

(If you’ve ever tried to get online at an airport or hotel, you’ve likely encountered the 511 error.)

HTTP 520 Unknown Error

This error code is not part of the HTTP standard, but is used by several large providers of server infrastructure-as-a-service, such a CloudFlare. It is used as a general “catch-all” error for unidentified problems that result in a request not being filled.

HTTP 598 Network Read Timeout Error (Microsoft)

This error code is not part of the HTTP standard, but is used by Microsoft HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.

HTTP 599 Network Connect Timeout Error (Microsoft)

This error code is not part of the HTTP standard, but is used by Microsoft HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.

Resources

IANA: the website of the Internet Assigned Numbers Authority.
HTTP Status Code Registry: the official IANA page with links to RFCs for each code.

Become Your Own ISP Today

Cost of Building a Website

All About The Dark Web & Tor

Become Internet Famous