Http error class

Информационные 100 Continue «Продолжить». Этот промежуточный ответ указывает, что запрос успешно
принят и клиент может продолжать присылать запросы либо проигнорировать
этот ответ, если запрос был завершён. Только HTTP/1.1 101 Switching Protocol «Переключение протокола». Этот код присылается в ответ на запрос
клиента, содержащий заголовок Upgrade:, и указывает, что
сервер переключился на протокол, который был указан в заголовке. Эта
возможность позволяет перейти на несовместимую версию протокола и обычно
не используется. Только HTTP/1.1 102 Processing «В обработке». Этот код указывает, что сервер получил запрос и
обрабатывает его, но обработка ещё не завершена. Только HTTP/1.1 103 Early Hints «Ранние подсказки». В ответе сообщаются ресурсы, которые могут быть
загружены заранее, пока сервер будет подготавливать основной ответ.
RFC 8297 (Experimental). Только HTTP/1.1 Успешные 200

OK

«Успешно». Запрос успешно обработан. Что значит «успешно», зависит от
метода HTTP, который был запрошен:

• GET: «ПОЛУЧИТЬ». Запрошенный ресурс был найден и передан в теле
  ответа.
• HEAD: «ЗАГОЛОВОК». Заголовки переданы в ответе.
• POST: «ПОСЫЛКА». Ресурс, описывающий результат действия сервера на
  запрос, передан в теле ответа.
• TRACE: «ОТСЛЕЖИВАТЬ». Тело ответа содержит тело запроса полученного
  сервером.

HTTP/0.9 и выше 201 Created «Создано». Запрос успешно выполнен и в результате был создан ресурс.
Этот код обычно присылается в ответ на запрос PUT «ПОМЕСТИТЬ». HTTP/0.9 и выше 202 Accepted «Принято». Запрос принят, но ещё не обработан. Не поддерживаемо, т.е.,
нет способа с помощью HTTP отправить асинхронный ответ позже, который
будет показывать итог обработки запроса. Это предназначено для случаев,
когда запрос обрабатывается другим процессом или сервером, либо для
пакетной обработки. HTTP/0.9 и выше 203 Non-Authoritative Information «Информация не авторитетна». Этот код ответа означает, что информация,
которая возвращена, была предоставлена не от исходного сервера, а из
какого-нибудь другого источника. Во всех остальных ситуациях более
предпочтителен код ответа 200 OK. HTTP/0.9 и 1.1 204 No Content «Нет содержимого». Нет содержимого для ответа на запрос, но заголовки
ответа, которые могут быть полезны, присылаются. Клиент может
использовать их для обновления кешированных заголовков полученных ранее
для этого ресурса. HTTP/0.9 и выше 205 Reset Content «Сбросить содержимое». Этот код присылается, когда запрос обработан,
чтобы сообщить клиенту, что необходимо сбросить отображение документа,
который прислал этот запрос. Только HTTP/1.1 206 Partial Content «Частичное содержимое». Этот код ответа используется, когда клиент
присылает заголовок диапазона, чтобы выполнить загрузку отдельно, в
несколько потоков. Только HTTP/1.1 Сообщения о перенаправлениях 300 Multiple Choice

«Множественный выбор». Этот код ответа присылается, когда запрос имеет
более чем один из возможных ответов. И User-agent или пользователь
должен выбрать один из ответов. Не существует стандартизированного
способа выбора одного из полученных ответов.

HTTP/1.0 и выше 301 Moved Permanently

«Перемещён на постоянной основе». Этот код ответа значит, что URI
запрашиваемого ресурса был изменён. Возможно, новый URI будет
предоставлен в ответе.

HTTP/0.9 и выше 302 Found

«Найдено». Этот код ответа значит, что запрошенный ресурс
временно изменён. Новые изменения в URI могут быть доступны в
будущем. Таким образом, этот URI, должен быть использован клиентом в
будущих запросах.

HTTP/0.9 и выше 303 See Other «Просмотр других ресурсов». Этот код ответа присылается, чтобы
направлять клиента для получения запрашиваемого ресурса в другой URI с
запросом GET. HTTP/0.9 и 1.1 304 Not Modified «Не модифицировано». Используется для кеширования. Это код ответа
значит, что запрошенный ресурс не был изменён. Таким образом, клиент
может продолжать использовать кешированную версию ответа. HTTP/0.9 и выше 305 Use Proxy «Использовать прокси». Это означает, что запрошенный ресурс должен быть
доступен через прокси. Этот код ответа в основном не поддерживается из
соображений безопасности. Только HTTP/1.1 306 Switch Proxy Больше не использовать. Изначально подразумевалось, что » последующие
запросы должны использовать указанный прокси.» Только HTTP/1.1 307 Temporary Redirect «Временное перенаправление». Сервер отправил этот ответ, чтобы клиент
получил запрошенный ресурс на другой URL-адрес с тем же методом, который
использовал предыдущий запрос. Данный код имеет ту же семантику, что код
ответа 302 Found, за исключением того, что агент
пользователя не должен изменять используемый метод HTTP: если в первом
запросе использовался POST, то во втором запросе также
должен использоваться POST. Только HTTP/1.1 308 Permanent Redirect

«Перенаправление на постоянной основе». Это означает, что ресурс
теперь постоянно находится в другом URI, указанном в заголовке
Location: HTTP Response. Данный код ответа имеет ту же
семантику, что и код ответа 301 Moved Permanently, за
исключением того, что агент пользователя не должен изменять
используемый метод HTTP: если POST использовался в первом
запросе, POST должен использоваться и во втором запросе.

Примечание: Это экспериментальный код ответа,
Спецификация которого в настоящее время находится в черновом виде.

draft-reschke-http-status-308 Клиентские 400 Bad Request «Плохой запрос». Этот ответ означает, что сервер не понимает запрос
из-за неверного синтаксиса. HTTP/0.9 и выше 401 Unauthorized «Неавторизованно». Для получения запрашиваемого ответа нужна
аутентификация. Статус похож на статус 403, но,в этом случае,
аутентификация возможна. HTTP/0.9 и выше 402 Payment Required «Необходима оплата». Этот код ответа зарезервирован для будущего
использования. Первоначальная цель для создания этого кода была в
использовании его для цифровых платёжных систем(на данный момент не
используется). HTTP/0.9 и 1.1 403 Forbidden «Запрещено». У клиента нет прав доступа к содержимому, поэтому сервер
отказывается дать надлежащий ответ. HTTP/0.9 и выше 404 Not Found «Не найден». Сервер не может найти запрашиваемый ресурс. Код этого
ответа, наверно, самый известный из-за частоты его появления в вебе. HTTP/0.9 и выше 405 Method Not Allowed «Метод не разрешён». Сервер знает о запрашиваемом методе, но он был
деактивирован и не может быть использован. Два обязательных метода,
GET и HEAD, никогда не должны быть
деактивированы и не должны возвращать этот код ошибки. Только HTTP/1.1 406 Not Acceptable

Этот ответ отсылается, когда веб сервер после выполнения
server-driven content negotiation, не нашёл контента, отвечающего критериям, полученным из user agent.

Только HTTP/1.1 407 Proxy Authentication Required Этот код ответа аналогичен коду 401, только аутентификация требуется для
прокси сервера. Только HTTP/1.1 408 Request Timeout Ответ с таким кодом может прийти, даже без предшествующего запроса. Он
означает, что сервер хотел бы отключить это неиспользуемое соединение.
Этот метод используется все чаще с тех пор, как некоторые браузеры,
вроде Chrome и IE9, стали использовать
HTTP механизмы предварительного соединения
для ускорения сёрфинга (смотрите баг 634278, будущей
реализации этого механизма в Firefox). Также учитывайте, что некоторые
серверы прерывают соединения не отправляя подобных сообщений. Только HTTP/1.1 409 Conflict

Этот ответ отсылается, когда запрос конфликтует с текущим состоянием
сервера.

Только HTTP/1.1 410 Gone

Этот ответ отсылается, когда запрашиваемый контент удалён с сервера.

Только HTTP/1.1 411 Length Required

Запрос отклонён, потому что сервер требует указание заголовка
Content-Length, но он не указан.

Только HTTP/1.1 412 Precondition Failed Клиент указал в своих заголовках условия, которые сервер не может
выполнить Только HTTP/1.1 413 Request Entity Too Large

Размер запроса превышает лимит, объявленный сервером. Сервер может
закрыть соединение, вернув заголовок Retry-After

Только HTTP/1.1 414 Request-URI Too Long URI запрашиваемый клиентом слишком длинный для того, чтобы сервер смог
его обработать Только HTTP/1.1 415 Unsupported Media Type Медиа формат запрашиваемых данных не поддерживается сервером, поэтому
запрос отклонён Только HTTP/1.1 416 Requested Range Not Satisfiable Диапазон указанный заголовком запроса Range не может быть
выполнен; возможно, он выходит за пределы переданного URI Только HTTP/1.1 417 Expectation Failed Этот код ответа означает, что ожидание, полученное из заголовка запроса
Expect, не может быть выполнено сервером. Только HTTP/1.1 Серверные 500 Internal Server Error «Внутренняя ошибка сервера». Сервер столкнулся с ситуацией, которую он
не знает как обработать. HTTP/0.9 и выше 501 Not Implemented «Не реализовано». Метод запроса не поддерживается сервером и не может быть
обработан. Единственные методы, которые сервера должны поддерживать (и,
соответственно, не должны возвращать этот код) — GET и
HEAD. HTTP/0.9 и выше 502 Bad Gateway «Плохой шлюз». Эта ошибка означает что сервер, во время работы в
качестве шлюза для получения ответа, нужного для обработки запроса,
получил недействительный (недопустимый) ответ. HTTP/0.9 и выше 503 Service Unavailable «Сервис недоступен». Сервер не готов обрабатывать запрос. Зачастую
причинами являются отключение сервера или то, что он перегружен.
Обратите внимание, что вместе с этим ответом удобная для
пользователей(user-friendly) страница должна отправлять объяснение
проблемы. Этот ответ должен использоваться для временных условий и
Retry-After: HTTP-заголовок должен, если возможно,
содержать предполагаемое время до восстановления сервиса. Веб-мастер
также должен позаботиться о заголовках, связанных с кешем, которые
отправляются вместе с этим ответом, так как эти ответы, связанные с
временными условиями, обычно не должны кешироваться. HTTP/0.9 и выше 504 Gateway Timeout Этот ответ об ошибке предоставляется, когда сервер действует как шлюз и
не может получить ответ вовремя. Только HTTP/1.1 505 HTTP Version Not Supported «HTTP-версия не поддерживается». HTTP-версия, используемая в запросе, не
поддерживается сервером. Только HTTP/1.1

HTTP error classes

This package provides error classes for every HTTP 4xx and 5xx error code. This makes it easy to throw HTTP errors in your application without having to build the classes yourself for that, just a small win.

You can also check if an error is a HttpError by checking if it’s an instance of the HttpError class from this package, all errors here extend that class.

The error classes allow you to provide a message and a context object, status codes are built into the errors. You can also just use the HttpError class to provide your own status code.

Example

Throwing an error with some context

Here we have a function to calculate the Fibonacci value at n steps. If the n we receive is not a number then we’ll throw a BadRequestError and give the n we received as context.

const { BadRequestError } = require("http-error-classes");

const fibonacci = (n) => {
  if (typeof n !== "number") {
    throw new BadRequestError("n must be a number!", { n });
  }
  // Calculate fibonacci
};

Filtering for HttpErrors

Here we have an express error middleware that handles how errors get returned to the client. We don’t want to expose errors that are not HttpErrors, so we mask them with a generic InternalServerError. It’s also important to explicitly map the error to the returned object because HttpErrors, like regular Errors, contain the stack trace which should not be exposed.

const { HttpError, InternalServerError } = require("http-error-classes");

const errorHandlerMiddleware = (err, req, res, next) => {
  const error = err instanceof HttpError ? err : new InternalServerError();
  res.status(error.status).send({
    message: error.message,
    context: error.context,
  });
};

API

HttpError

declare class HttpError<ContextType> extends Error {
  readonly status: number;
  readonly message: string;
  readonly context?: ContextType | undefined;
  readonly name: string;
  readonly statusCode: number;

  constructor(
    status: number,
    message: string,
    context?: ContextType | undefined = undefined
  );
}

Any other error, for example BadRequestError

declare class BadRequestError<ContextType> extends HttpError<ContextType> {
  readonly message: string;
  readonly context?: ContextType | undefined;
  readonly name = "BadRequestError";

  constructor(
    message?: string = "Bad Request",
    context?: ContextType | undefined = undefined
  );
}

From Wikipedia, the free encyclopedia

This is a list of Hypertext Transfer Protocol (HTTP) response status codes. Status codes are issued by a server in response to a client’s request made to the server. It includes codes from IETF Request for Comments (RFCs), other specifications, and some additional codes used in some common applications of the HTTP. The first digit of the status code specifies one of five standard classes of responses. The optional message phrases shown are typical, but any human-readable alternative may be provided, or none at all.

Unless otherwise stated, the status code is part of the HTTP standard (RFC 9110).

The Internet Assigned Numbers Authority (IANA) maintains the official registry of HTTP status codes.^[1]

All HTTP response status codes are separated into five classes or categories. The first digit of the status code defines the class of response, while the last two digits do not have any classifying or categorization role. There are five classes defined by the standard:

• 1xx informational response – the request was received, continuing process
• 2xx successful – the request was successfully received, understood, and accepted
• 3xx redirection – further action needs to be taken in order to complete the request
• 4xx client error – the request contains bad syntax or cannot be fulfilled
• 5xx server error – the server failed to fulfil an apparently valid request

1xx informational response

An informational response indicates that the request was received and understood. It is issued on a provisional basis while request processing continues. It alerts the client to wait for a final response. The message consists only of the status line and optional header fields, and is terminated by an empty line. As the HTTP/1.0 standard did not define any 1xx status codes, servers must not^{[note 1]} send a 1xx response to an HTTP/1.0 compliant client except under experimental conditions.

100 Continue

The server has received the request headers and the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). Sending a large request body to a server after a request has been rejected for inappropriate headers would be inefficient. To have a server check the request’s headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. If the client receives an error code such as 403 (Forbidden) or 405 (Method Not Allowed) then it should not send the request’s body. The response 417 Expectation Failed indicates that the request should be repeated without the Expect header as it indicates that the server does not support expectations (this is the case, for example, of HTTP/1.0 servers).^[2]

101 Switching Protocols

The requester has asked the server to switch protocols and the server has agreed to do so.

102 Processing (WebDAV; RFC 2518)

A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet.^[3] This prevents the client from timing out and assuming the request was lost.

103 Early Hints (RFC 8297)

Used to return some response headers before final HTTP message.^[4]

2xx success

This class of status codes indicates the action requested by the client was received, understood, and accepted.^[1]

200 OK

Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request, the response will contain an entity describing or containing the result of the action.

201 Created

The request has been fulfilled, resulting in the creation of a new resource.^[5]

202 Accepted

The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.

203 Non-Authoritative Information (since HTTP/1.1)

The server is a transforming proxy (e.g. a Web accelerator) that received a 200 OK from its origin, but is returning a modified version of the origin’s response.^[6][7]

204 No Content

The server successfully processed the request, and is not returning any content.

205 Reset Content

The server successfully processed the request, asks that the requester reset its document view, and is not returning any content.

206 Partial Content

The server is delivering only part of the resource (byte serving) due to a range header sent by the client. The range header is used by HTTP clients to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.

207 Multi-Status (WebDAV; RFC 4918)

The message body that follows is by default an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.^[8]

208 Already Reported (WebDAV; RFC 5842)

The members of a DAV binding have already been enumerated in a preceding part of the (multistatus) response, and are not being included again.

226 IM Used (RFC 3229)

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.^[9]

3xx redirection

This class of status code indicates the client must take additional action to complete the request. Many of these status codes are used in URL redirection.^[1]

A user agent may carry out the additional action with no user interaction only if the method used in the second request is GET or HEAD. A user agent may automatically redirect a request. A user agent should detect and intervene to prevent cyclical redirects.^[10]

300 Multiple Choices

Indicates multiple options for the resource from which the client may choose (via agent-driven content negotiation). For example, this code could be used to present multiple video format options, to list files with different filename extensions, or to suggest word-sense disambiguation.

301 Moved Permanently

This and all future requests should be directed to the given URI.

302 Found (Previously «Moved temporarily»)

Tells the client to look at (browse to) another URL. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect with the same method (the original describing phrase was «Moved Temporarily»),^[11] but popular browsers implemented 302 redirects by changing the method to GET. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours.^[10]

303 See Other (since HTTP/1.1)

The response to the request can be found under another URI using the GET method. When received in response to a POST (or PUT/DELETE), the client should presume that the server has received the data and should issue a new GET request to the given URI.

304 Not Modified

Indicates that the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match. In such case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.

305 Use Proxy (since HTTP/1.1)

The requested resource is available only through a proxy, the address for which is provided in the response. For security reasons, many HTTP clients (such as Mozilla Firefox and Internet Explorer) do not obey this status code.

306 Switch Proxy

No longer used. Originally meant «Subsequent requests should use the specified proxy.»

307 Temporary Redirect (since HTTP/1.1)

In this case, the request should be repeated with another URI; however, future requests should still use the original URI. In contrast to how 302 was historically implemented, the request method is not allowed to be changed when reissuing the original request. For example, a POST request should be repeated using another POST request.

308 Permanent Redirect

This and all future requests should be directed to the given URI. 308 parallel the behaviour of 301, but does not allow the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.

4xx client errors

This class of status code is intended for situations in which the error seems to have been caused by the client. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents should display any included entity to the user.

400 Bad Request

The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, size too large, invalid request message framing, or deceptive request routing).

401 Unauthorized

Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication. 401 semantically means «unauthorised», the user does not have valid authentication credentials for the target resource.

Some sites incorrectly issue HTTP 401 when an IP address is banned from the website (usually the website domain) and that specific address is refused permission to access a website.^{[citation needed]}

402 Payment Required

Reserved for future use. The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, as proposed, for example, by GNU Taler,^[13] but that has not yet happened, and this code is not widely used. Google Developers API uses this status if a particular developer has exceeded the daily limit on requests.^[14] Sipgate uses this code if an account does not have sufficient funds to start a call.^[15] Shopify uses this code when the store has not paid their fees and is temporarily disabled.^[16] Stripe uses this code for failed payments where parameters were correct, for example blocked fraudulent payments.^[17]

403 Forbidden

The request contained valid data and was understood by the server, but the server is refusing action. This may be due to the user not having the necessary permissions for a resource or needing an account of some sort, or attempting a prohibited action (e.g. creating a duplicate record where only one is allowed). This code is also typically used if the request provided authentication by answering the WWW-Authenticate header field challenge, but the server did not accept that authentication. The request should not be repeated.

404 Not Found

The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.

405 Method Not Allowed

A request method is not supported for the requested resource; for example, a GET request on a form that requires data to be presented via POST, or a PUT request on a read-only resource.

406 Not Acceptable

The requested resource is capable of generating only content not acceptable according to the Accept headers sent in the request. See Content negotiation.

407 Proxy Authentication Required

The client must first authenticate itself with the proxy.

408 Request Timeout

The server timed out waiting for the request. According to HTTP specifications: «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.»

409 Conflict

Indicates that the request could not be processed because of conflict in the current state of the resource, such as an edit conflict between multiple simultaneous updates.

410 Gone

Indicates that the resource requested was previously in use but is no longer available and will not be available again. This should be used when a resource has been intentionally removed and the resource should be purged. Upon receiving a 410 status code, the client should not request the resource in the future. Clients such as search engines should remove the resource from their indices. Most use cases do not require clients and search engines to purge the resource, and a «404 Not Found» may be used instead.

411 Length Required

The request did not specify the length of its content, which is required by the requested resource.

412 Precondition Failed

The server does not meet one of the preconditions that the requester put on the request header fields.

413 Payload Too Large

The request is larger than the server is willing or able to process. Previously called «Request Entity Too Large» in RFC 2616.^[18]

414 URI Too Long

The URI provided was too long for the server to process. Often the result of too much data being encoded as a query-string of a GET request, in which case it should be converted to a POST request. Called «Request-URI Too Long» previously in RFC 2616.^[19]

415 Unsupported Media Type

The request entity has a media type which the server or resource does not support. For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.

416 Range Not Satisfiable

The client has asked for a portion of the file (byte serving), but the server cannot supply that portion. For example, if the client asked for a part of the file that lies beyond the end of the file. Called «Requested Range Not Satisfiable» previously RFC 2616.^[20]

417 Expectation Failed

The server cannot meet the requirements of the Expect request-header field.^[21]

418 I’m a teapot (RFC 2324, RFC 7168)

This code was defined in 1998 as one of the traditional IETF April Fools’ jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. The RFC specifies this code should be returned by teapots requested to brew coffee.^[22] This HTTP status is used as an Easter egg in some websites, such as Google.com’s «I’m a teapot» easter egg.^[23][24][25] Sometimes, this status code is also used as a response to a blocked request, instead of the more appropriate 403 Forbidden.^[26][27]

421 Misdirected Request

The request was directed at a server that is not able to produce a response (for example because of connection reuse).

422 Unprocessable Entity

The request was well-formed but was unable to be followed due to semantic errors.^[8]

423 Locked (WebDAV; RFC 4918)

The resource that is being accessed is locked.^[8]

424 Failed Dependency (WebDAV; RFC 4918)

The request failed because it depended on another request and that request failed (e.g., a PROPPATCH).^[8]

425 Too Early (RFC 8470)

Indicates that the server is unwilling to risk processing a request that might be replayed.

426 Upgrade Required

The client should switch to a different protocol such as TLS/1.3, given in the Upgrade header field.

428 Precondition Required (RFC 6585)

The origin server requires the request to be conditional. 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.^[28]

429 Too Many Requests (RFC 6585)

The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.^[28]

431 Request Header Fields Too Large (RFC 6585)

The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large.^[28]

451 Unavailable For Legal Reasons (RFC 7725)

A server operator has received a legal demand to deny access to a resource or to a set of resources that includes the requested resource.^[29] The code 451 was chosen as a reference to the novel Fahrenheit 451 (see the Acknowledgements in the RFC).

5xx server errors

The server failed to fulfil a request.

Response status codes beginning with the digit «5» indicate cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and indicate whether it is a temporary or permanent condition. Likewise, user agents should display any included entity to the user. These response codes are applicable to any request method.

500 Internal Server Error

A generic error message, given when an unexpected condition was encountered and no more specific message is suitable.

501 Not Implemented

The server either does not recognize the request method, or it lacks the ability to fulfil the request. Usually this implies future availability (e.g., a new feature of a web-service API).

502 Bad Gateway

The server was acting as a gateway or proxy and received an invalid response from the upstream server.

503 Service Unavailable

The server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state.^[30]

504 Gateway Timeout

The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.

505 HTTP Version Not Supported

The server does not support the HTTP version used in the request.

506 Variant Also Negotiates (RFC 2295)

Transparent content negotiation for the request results in a circular reference.^[31]

507 Insufficient Storage (WebDAV; RFC 4918)

The server is unable to store the representation needed to complete the request.^[8]

508 Loop Detected (WebDAV; RFC 5842)

The server detected an infinite loop while processing the request (sent instead of 208 Already Reported).

510 Not Extended (RFC 2774)

Further extensions to the request are required for the server to fulfill it.^[32]

511 Network Authentication Required (RFC 6585)

The client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g., «captive portals» used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot).^[28]

Unofficial codes

The following codes are not specified by any standard.

419 Page Expired (Laravel Framework)

Used by the Laravel Framework when a CSRF Token is missing or expired.

420 Method Failure (Spring Framework)

A deprecated response used by the Spring Framework when a method has failed.^[33]

420 Enhance Your Calm (Twitter)

Returned by version 1 of the Twitter Search and Trends API when the client is being rate limited; versions 1.1 and later use the 429 Too Many Requests response code instead.^[34] The phrase «Enhance your calm» comes from the 1993 movie Demolition Man, and its association with this number is likely a reference to cannabis.^{[citation needed]}

430 Request Header Fields Too Large (Shopify)

Used by Shopify, instead of the 429 Too Many Requests response code, when too many URLs are requested within a certain time frame.^[35]

450 Blocked by Windows Parental Controls (Microsoft)

The Microsoft extension code indicated when Windows Parental Controls are turned on and are blocking access to the requested webpage.^[36]

498 Invalid Token (Esri)

Returned by ArcGIS for Server. Code 498 indicates an expired or otherwise invalid token.^[37]

499 Token Required (Esri)

Returned by ArcGIS for Server. Code 499 indicates that a token is required but was not submitted.^[37]

509 Bandwidth Limit Exceeded (Apache Web Server/cPanel)

The server has exceeded the bandwidth specified by the server administrator; this is often used by shared hosting providers to limit the bandwidth of customers.^[38]

529 Site is overloaded

Used by Qualys in the SSLLabs server testing API to signal that the site can’t process the request.^[39]

530 Site is frozen

Used by the Pantheon Systems web platform to indicate a site that has been frozen due to inactivity.^[40]

598 (Informal convention) Network read timeout error

Used by some HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.^[41]

599 Network Connect Timeout Error

An error used by some HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.

Internet Information Services

Microsoft’s Internet Information Services (IIS) web server expands the 4xx error space to signal errors with the client’s request.

440 Login Time-out

The client’s session has expired and must log in again.^[42]

449 Retry With

The server cannot honour the request because the user has not provided the required information.^[43]

451 Redirect

Used in Exchange ActiveSync when either a more efficient server is available or the server cannot access the users’ mailbox.^[44] The client is expected to re-run the HTTP AutoDiscover operation to find a more appropriate server.^[45]

IIS sometimes uses additional decimal sub-codes for more specific information,^[46] however these sub-codes only appear in the response payload and in documentation, not in the place of an actual HTTP status code.

nginx

The nginx web server software expands the 4xx error space to signal issues with the client’s request.^[47][48]

444 No Response

Used internally^[49] to instruct the server to return no information to the client and close the connection immediately.

494 Request header too large

Client sent too large request or too long header line.

495 SSL Certificate Error

An expansion of the 400 Bad Request response code, used when the client has provided an invalid client certificate.

496 SSL Certificate Required

An expansion of the 400 Bad Request response code, used when a client certificate is required but not provided.

497 HTTP Request Sent to HTTPS Port

An expansion of the 400 Bad Request response code, used when the client has made a HTTP request to a port listening for HTTPS requests.

499 Client Closed Request

Used when the client has closed the request before the server could send a response.

Cloudflare

Cloudflare’s reverse proxy service expands the 5xx series of errors space to signal issues with the origin server.^[50]

520 Web Server Returned an Unknown Error

The origin server returned an empty, unknown, or unexpected response to Cloudflare.^[51]

521 Web Server Is Down

The origin server refused connections from Cloudflare. Security solutions at the origin may be blocking legitimate connections from certain Cloudflare IP addresses.

522 Connection Timed Out

Cloudflare timed out contacting the origin server.

523 Origin Is Unreachable

Cloudflare could not reach the origin server; for example, if the DNS records for the origin server are incorrect or missing.

524 A Timeout Occurred

Cloudflare was able to complete a TCP connection to the origin server, but did not receive a timely HTTP response.

525 SSL Handshake Failed

Cloudflare could not negotiate a SSL/TLS handshake with the origin server.

526 Invalid SSL Certificate

Cloudflare could not validate the SSL certificate on the origin web server. Also used by Cloud Foundry’s gorouter.

527 Railgun Error

Error 527 indicates an interrupted connection between Cloudflare and the origin server’s Railgun server.^[52]

530

Error 530 is returned along with a 1xxx error.^[53]

AWS Elastic Load Balancer

Amazon’s Elastic Load Balancing adds a few custom return codes

460

Client closed the connection with the load balancer before the idle timeout period elapsed. Typically when client timeout is sooner than the Elastic Load Balancer’s timeout.^[54]

463

The load balancer received an X-Forwarded-For request header with more than 30 IP addresses.^[54]

561 Unauthorized

An error around authentication returned by a server registered with a load balancer. You configured a listener rule to authenticate users, but the identity provider (IdP) returned an error code when authenticating the user.^[55]

Caching warning codes (obsoleted)

The following caching related warning codes were specified under RFC 7234. Unlike the other status codes above, these were not sent as the response status in the HTTP protocol, but as part of the «Warning» HTTP header.^[56][57]

Since this «Warning» header is often neither sent by servers nor acknowledged by clients, this header and its codes were obsoleted by the HTTP Working Group in 2022 with RFC 9111.^[58]

110 Response is Stale

The response provided by a cache is stale (the content’s age exceeds a maximum age set by a Cache-Control header or heuristically chosen lifetime).

111 Revalidation Failed

The cache was unable to validate the response, due to an inability to reach the origin server.

112 Disconnected Operation

The cache is intentionally disconnected from the rest of the network.

113 Heuristic Expiration

The cache heuristically chose a freshness lifetime greater than 24 hours and the response’s age is greater than 24 hours.

199 Miscellaneous Warning

Arbitrary, non-specific warning. The warning text may be logged or presented to the user.

214 Transformation Applied

Added by a proxy if it applies any transformation to the representation, such as changing the content encoding, media type or the like.

299 Miscellaneous Persistent Warning

Same as 199, but indicating a persistent warning.

See also

• Custom error pages
• List of FTP server return codes
• List of HTTP header fields
• List of SMTP server return codes
• Common Log Format

Explanatory notes

References

External links

• «RFC 9110: HTTP Semantics and Content, Section 15 «Status Codes»«.
• Hypertext Transfer Protocol (HTTP) Status Code Registry

It’s important to know your HTTP error codes even if you’re a network engineer. You don’t need to memorize them but know about them. You’ll almost always get called into or blamed for them :). I’m actually shocked at times when developers and other engineers have no clue about them.

For example, the “new” setup is giving a 500 error. Network, please check your side and maybe run a packet capture. Ummm, no. A 500 error is a server side error. So I know the network is not the first place you look. If the end user is getting a 500, that means the client is actually communicating with the server so it’s not network. I know just based off the error. The same goes for 400 errors. If the end user is getting a 404-Not Found or 403-Forbidden, we know that the communication is fine. Those are errors coming from the client but giving the error because of what the client got back from the server. HTTP 404 errors indicate the network connection between client and server was made successfully.

You can see it’s important to know how things work to help make troubleshooting more efficient. If you have both sides that don’t know what they are doing, you could spend hours looking into the network waisting time. At least on the network side, knowing these errors will help your team not waist time.

Now I’m not saying it’s never the network but 100% of the time it was never the network when I got the 400/500 error. Usually, if it’s the network, you won’t get any response. Or more than one thing will be down, not just that server. Even with a Firewall in between, if the port is not open, it’s going to timeout. You won’t get back the detailed error messages and the message you do get will be something like ERR_CONNECTION_REFUSED.

Types of HTTP Error and Status Codes:
100-199: informational status
200-299: success status
300-399: redirection status
400-499: client errors
500-599: server errors

It’s always good to check out the RFC’s at https://tools.ietf.org/html/. They have a lot of great information on a wide range of topics.  It’s a place used to develop a “standard” network protocol, a function of a network protocol or any feature which is related with network communication.  A good example is EIGRP.  We all know it’s a Cisco proprietary protocol.  You could only use it with Cisco hardware/software.  But the Functionality of EIGRP was converted to an open standard in 2013 and was published with informational status as RFC 7868 in 2016. It’s a stripped down version but you can see that IETF has detailed information about it.

Below is for Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content which lists all the HTTP Error and Status Codes with some good information about them.

6.2. Informational 1xx

The 1xx (Informational) class of status code indicates an interim
response for communicating connection status or request progress
prior to completing the requested action and sending a final
response. 1xx responses are terminated by the first empty line after
the status-line (the empty line signaling the end of the header
section). Since HTTP/1.0 did not define any 1xx status codes, a
server MUST NOT send a 1xx response to an HTTP/1.0 client.

A client MUST be able to parse one or more 1xx responses received
prior to a final response, even if the client does not expect one. A
user agent MAY ignore unexpected 1xx responses.

A proxy MUST forward 1xx responses unless the proxy itself requested
the generation of the 1xx response. For example, if a proxy adds an
“Expect: 100-continue” field when it forwards a request, then it need
not forward the corresponding 100 (Continue) response(s).

6.2.1. 100 Continue

The 100 (Continue) status code indicates that the initial part of a
request has been received and has not yet been rejected by the
server. The server intends to send a final response after the
request has been fully received and acted upon.

When the request contains an Expect header field that includes a
100-continue expectation, the 100 response indicates that the server
wishes to receive the request payload body, as described in
Section 5.1.1. The client ought to continue sending the request and
discard the 100 response.

If the request did not contain an Expect header field containing the
100-continue expectation, the client can simply discard this interim
response.

6.2.2. 101 Switching Protocols

The 101 (Switching Protocols) status code indicates that the server
understands and is willing to comply with the client’s request, via
the Upgrade header field (Section 6.7 of [RFC7230]), for a change in
the application protocol being used on this connection. The server

Fielding & Reschke Standards Track [Page 50]

RFC 7231 HTTP/1.1 Semantics and Content June 2014

MUST generate an Upgrade header field in the response that indicates
which protocol(s) will be switched to immediately after the empty
line that terminates the 101 response.

It is assumed that the server will only agree to switch protocols
when it is advantageous to do so. For example, switching to a newer
version of HTTP might be advantageous over older versions, and
switching to a real-time, synchronous protocol might be advantageous
when delivering resources that use such features.

6.3. Successful 2xx

The 2xx (Successful) class of status code indicates that the client’s
request was successfully received, understood, and accepted.

6.3.1. 200 OK

The 200 (OK) status code indicates that the request has succeeded.
The payload sent in a 200 response depends on the request method.
For the methods defined by this specification, the intended meaning
of the payload can be summarized as:

GET a representation of the target resource;

HEAD the same representation as GET, but without the representation
data;

POST a representation of the status of, or results obtained from,
the action;

PUT, DELETE a representation of the status of the action;

OPTIONS a representation of the communications options;

TRACE a representation of the request message as received by the end
server.

Aside from responses to CONNECT, a 200 response always has a payload,
though an origin server MAY generate a payload body of zero length.
If no payload is desired, an origin server ought to send 204 (No
Content) instead. For CONNECT, no payload is allowed because the
successful result is a tunnel, which begins immediately after the 200
response header section.

A 200 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]).

Fielding & Reschke Standards Track [Page 51]

RFC 7231 HTTP/1.1 Semantics and Content June 2014

6.3.2. 201 Created

The 201 (Created) status code indicates that the request has been
fulfilled and has resulted in one or more new resources being
created. The primary resource created by the request is identified
by either a Location header field in the response or, if no Location
field is received, by the effective request URI.

The 201 response payload typically describes and links to the
resource(s) created. See Section 7.2 for a discussion of the meaning
and purpose of validator header fields, such as ETag and
Last-Modified, in a 201 response.

6.3.3. 202 Accepted

The 202 (Accepted) status code indicates that the request has been
accepted for processing, but the processing has not been completed.
The request might or might not eventually be acted upon, as it might
be disallowed when processing actually takes place. There is no
facility in HTTP for re-sending a status code from an asynchronous
operation.

The 202 response is intentionally noncommittal. Its purpose is to
allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without
requiring that the user agent’s connection to the server persist
until the process is completed. The representation sent with this
response ought to describe the request’s current status and point to
(or embed) a status monitor that can provide the user with an
estimate of when the request will be fulfilled.

6.3.4. 203 Non-Authoritative Information

The 203 (Non-Authoritative Information) status code indicates that
the request was successful but the enclosed payload has been modified
from that of the origin server’s 200 (OK) response by a transforming
proxy (Section 5.7.2 of [RFC7230]). This status code allows the
proxy to notify recipients when a transformation has been applied,
since that knowledge might impact later decisions regarding the
content. For example, future cache validation requests for the
content might only be applicable along the same request path (through
the same proxies).

The 203 response is similar to the Warning code of 214 Transformation
Applied (Section 5.5 of [RFC7234]), which has the advantage of being
applicable to responses with any status code.

Fielding & Reschke Standards Track [Page 52]

RFC 7231 HTTP/1.1 Semantics and Content June 2014

A 203 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]).

6.3.5. 204 No Content

The 204 (No Content) status code indicates that the server has
successfully fulfilled the request and that there is no additional
content to send in the response payload body. Metadata in the
response header fields refer to the target resource and its selected
representation after the requested action was applied.

For example, if a 204 status code is received in response to a PUT
request and the response contains an ETag header field, then the PUT
was successful and the ETag field-value contains the entity-tag for
the new representation of that target resource.

The 204 response allows a server to indicate that the action has been
successfully applied to the target resource, while implying that the
user agent does not need to traverse away from its current “document
view” (if any). The server assumes that the user agent will provide
some indication of the success to its user, in accord with its own
interface, and apply any new or updated metadata in the response to
its active representation.

For example, a 204 status code is commonly used with document editing
interfaces corresponding to a “save” action, such that the document
being saved remains available to the user for editing. It is also
frequently used with interfaces that expect automated data transfers
to be prevalent, such as within distributed version control systems.

A 204 response is terminated by the first empty line after the header
fields because it cannot contain a message body.

A 204 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]).

6.3.6. 205 Reset Content

The 205 (Reset Content) status code indicates that the server has
fulfilled the request and desires that the user agent reset the
“document view”, which caused the request to be sent, to its original
state as received from the origin server.

This response is intended to support a common data entry use case
where the user receives content that supports data entry (a form,
notepad, canvas, etc.), enters or manipulates data in that space,

Fielding & Reschke Standards Track [Page 53]

RFC 7231 HTTP/1.1 Semantics and Content June 2014

causes the entered data to be submitted in a request, and then the
data entry mechanism is reset for the next entry so that the user can
easily initiate another input action.

Since the 205 status code implies that no additional content will be
provided, a server MUST NOT generate a payload in a 205 response. In
other words, a server MUST do one of the following for a 205
response: a) indicate a zero-length body for the response by
including a Content-Length header field with a value of 0; b)
indicate a zero-length payload for the response by including a
Transfer-Encoding header field with a value of chunked and a message
body consisting of a single chunk of zero-length; or, c) close the
connection immediately after sending the blank line terminating the
header section.

6.4. Redirection 3xx

The 3xx (Redirection) class of status code indicates that further
action needs to be taken by the user agent in order to fulfill the
request. If a Location header field (Section 7.1.2) is provided, the
user agent MAY automatically redirect its request to the URI
referenced by the Location field value, even if the specific status
code is not understood. Automatic redirection needs to done with
care for methods not known to be safe, as defined in Section 4.2.1,
since the user might not wish to redirect an unsafe request.

There are several types of redirects:

1. Redirects that indicate the resource might be available at a
different URI, as provided by the Location field, as in the
status codes 301 (Moved Permanently), 302 (Found), and 307
(Temporary Redirect).

2. Redirection that offers a choice of matching resources, each
capable of representing the original request target, as in the
300 (Multiple Choices) status code.

3. Redirection to a different resource, identified by the Location
field, that can represent an indirect response to the request, as
in the 303 (See Other) status code.

4. Redirection to a previously cached result, as in the 304 (Not
Modified) status code.

Note: In HTTP/1.0, the status codes 301 (Moved Permanently) and
302 (Found) were defined for the first type of redirect
([RFC1945], Section 9.3). Early user agents split on whether the
method applied to the redirect target would be the same as the

Fielding & Reschke Standards Track [Page 54]

RFC 7231 HTTP/1.1 Semantics and Content June 2014

original request or would be rewritten as GET. Although HTTP
originally defined the former semantics for 301 and 302 (to match
its original implementation at CERN), and defined 303 (See Other)
to match the latter semantics, prevailing practice gradually
converged on the latter semantics for 301 and 302 as well. The
first revision of HTTP/1.1 added 307 (Temporary Redirect) to
indicate the former semantics without being impacted by divergent
practice. Over 10 years later, most user agents still do method
rewriting for 301 and 302; therefore, this specification makes
that behavior conformant when the original request is POST.

A client SHOULD detect and intervene in cyclical redirections (i.e.,
“infinite” redirection loops).

Note: An earlier version of this specification recommended a
maximum of five redirections ([RFC2068], Section 10.3). Content
developers need to be aware that some clients might implement such
a fixed limitation.

6.4.1. 300 Multiple Choices

The 300 (Multiple Choices) status code indicates that the target
resource has more than one representation, each with its own more
specific identifier, and information about the alternatives is being
provided so that the user (or user agent) can select a preferred
representation by redirecting its request to one or more of those
identifiers. In other words, the server desires that the user agent
engage in reactive negotiation to select the most appropriate
representation(s) for its needs (Section 3.4).

If the server has a preferred choice, the server SHOULD generate a
Location header field containing a preferred choice’s URI reference.
The user agent MAY use the Location field value for automatic
redirection.

For request methods other than HEAD, the server SHOULD generate a
payload in the 300 response containing a list of representation
metadata and URI reference(s) from which the user or user agent can
choose the one most preferred. The user agent MAY make a selection
from that list automatically if it understands the provided media
type. A specific format for automatic selection is not defined by
this specification because HTTP tries to remain orthogonal to the
definition of its payloads. In practice, the representation is
provided in some easily parsed format believed to be acceptable to
the user agent, as determined by shared design or content
negotiation, or in some commonly accepted hypertext format.

Fielding & Reschke Standards Track [Page 55]

RFC 7231 HTTP/1.1 Semantics and Content June 2014

A 300 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]).

Note: The original proposal for the 300 status code defined the
URI header field as providing a list of alternative
representations, such that it would be usable for 200, 300, and
406 responses and be transferred in responses to the HEAD method.
However, lack of deployment and disagreement over syntax led to
both URI and Alternates (a subsequent proposal) being dropped from
this specification. It is possible to communicate the list using
a set of Link header fields [RFC5988], each with a relationship of
“alternate”, though deployment is a chicken-and-egg problem.

6.4.2. 301 Moved Permanently

The 301 (Moved Permanently) status code indicates that the target
resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs.
Clients with link-editing capabilities ought to automatically re-link
references to the effective request URI to one or more of the new
references sent by the server, where possible.

The server SHOULD generate a Location header field in the response
containing a preferred URI reference for the new permanent URI. The
user agent MAY use the Location field value for automatic
redirection. The server’s response payload usually contains a short
hypertext note with a hyperlink to the new URI(s).

Note: For historical reasons, a user agent MAY change the request
method from POST to GET for the subsequent request. If this
behavior is undesired, the 307 (Temporary Redirect) status code
can be used instead.

A 301 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]).

6.4.3. 302 Found

The 302 (Found) status code indicates that the target resource
resides temporarily under a different URI. Since the redirection
might be altered on occasion, the client ought to continue to use the
effective request URI for future requests.

Fielding & Reschke Standards Track [Page 56]

RFC 7231 HTTP/1.1 Semantics and Content June 2014

The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI. The user agent MAY
use the Location field value for automatic redirection. The server’s
response payload usually contains a short hypertext note with a
hyperlink to the different URI(s).

Note: For historical reasons, a user agent MAY change the request
method from POST to GET for the subsequent request. If this
behavior is undesired, the 307 (Temporary Redirect) status code
can be used instead.

6.4.4. 303 See Other

The 303 (See Other) status code indicates that the server is
redirecting the user agent to a different resource, as indicated by a
URI in the Location header field, which is intended to provide an
indirect response to the original request. A user agent can perform
a retrieval request targeting that URI (a GET or HEAD request if
using HTTP), which might also be redirected, and present the eventual
result as an answer to the original request. Note that the new URI
in the Location header field is not considered equivalent to the
effective request URI.

This status code is applicable to any HTTP method. It is primarily
used to allow the output of a POST action to redirect the user agent
to a selected resource, since doing so provides the information
corresponding to the POST response in a form that can be separately
identified, bookmarked, and cached, independent of the original
request.

A 303 response to a GET request indicates that the origin server does
not have a representation of the target resource that can be
transferred by the server over HTTP. However, the Location field
value refers to a resource that is descriptive of the target
resource, such that making a retrieval request on that other resource
might result in a representation that is useful to recipients without
implying that it represents the original target resource. Note that
answers to the questions of what can be represented, what
representations are adequate, and what might be a useful description
are outside the scope of HTTP.

Except for responses to a HEAD request, the representation of a 303
response ought to contain a short hypertext note with a hyperlink to
the same URI reference provided in the Location header field.

Fielding & Reschke Standards Track [Page 57]

RFC 7231 HTTP/1.1 Semantics and Content June 2014

6.4.5. 305 Use Proxy

The 305 (Use Proxy) status code was defined in a previous version of
this specification and is now deprecated (Appendix B).

6.4.6. 306 (Unused)

The 306 status code was defined in a previous version of this
specification, is no longer used, and the code is reserved.

6.4.7. 307 Temporary Redirect

The 307 (Temporary Redirect) status code indicates that the target
resource resides temporarily under a different URI and the user agent
MUST NOT change the request method if it performs an automatic
redirection to that URI. Since the redirection can change over time,
the client ought to continue using the original effective request URI
for future requests.

The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI. The user agent MAY
use the Location field value for automatic redirection. The server’s
response payload usually contains a short hypertext note with a
hyperlink to the different URI(s).

Note: This status code is similar to 302 (Found), except that it
does not allow changing the request method from POST to GET. This
specification defines no equivalent counterpart for 301 (Moved
Permanently) ([RFC7238], however, defines the status code 308
(Permanent Redirect) for this purpose).

6.5. Client Error 4xx

The 4xx (Client Error) class of status code indicates that the client
seems to have erred. Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent
condition. These status codes are applicable to any request method.
User agents SHOULD display any included representation to the user.

6.5.1. 400 Bad Request

The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).

Fielding & Reschke Standards Track [Page 58]

RFC 7231 HTTP/1.1 Semantics and Content June 2014

6.5.2. 402 Payment Required

The 402 (Payment Required) status code is reserved for future use.

6.5.3. 403 Forbidden

The 403 (Forbidden) status code indicates that the server understood
the request but refuses to authorize it. A server that wishes to
make public why the request has been forbidden can describe that
reason in the response payload (if any).

If authentication credentials were provided in the request, the
server considers them insufficient to grant access. The client
SHOULD NOT automatically repeat the request with the same
credentials. The client MAY repeat the request with new or different
credentials. However, a request might be forbidden for reasons
unrelated to the credentials.

An origin server that wishes to “hide” the current existence of a
forbidden target resource MAY instead respond with a status code of
404 (Not Found).

6.5.4. 404 Not Found

The 404 (Not Found) status code indicates that the origin server did
not find a current representation for the target resource or is not
willing to disclose that one exists. A 404 status code does not
indicate whether this lack of representation is temporary or
permanent; the 410 (Gone) status code is preferred over 404 if the
origin server knows, presumably through some configurable means, that
the condition is likely to be permanent.

A 404 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]).

6.5.5. 405 Method Not Allowed

The 405 (Method Not Allowed) status code indicates that the method
received in the request-line is known by the origin server but not
supported by the target resource. The origin server MUST generate an
Allow header field in a 405 response containing a list of the target
resource’s currently supported methods.

A 405 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]).

Fielding & Reschke Standards Track [Page 59]

RFC 7231 HTTP/1.1 Semantics and Content June 2014

6.5.6. 406 Not Acceptable

The 406 (Not Acceptable) status code indicates that the target
resource does not have a current representation that would be
acceptable to the user agent, according to the proactive negotiation
header fields received in the request (Section 5.3), and the server
is unwilling to supply a default representation.

The server SHOULD generate a payload containing a list of available
representation characteristics and corresponding resource identifiers
from which the user or user agent can choose the one most
appropriate. A user agent MAY automatically select the most
appropriate choice from that list. However, this specification does
not define any standard for such automatic selection, as described in
Section 6.4.1.

6.5.7. 408 Request Timeout

The 408 (Request Timeout) status code indicates that the server did
not receive a complete request message within the time that it was
prepared to wait. A server SHOULD send the “close” connection option
(Section 6.1 of [RFC7230]) in the response, since 408 implies that
the server has decided to close the connection rather than continue
waiting. If the client has an outstanding request in transit, the
client MAY repeat that request on a new connection.

6.5.8. 409 Conflict

The 409 (Conflict) status code indicates that the request could not
be completed due to a conflict with the current state of the target
resource. This code is used in situations where the user might be
able to resolve the conflict and resubmit the request. The server
SHOULD generate a payload that includes enough information for a user
to recognize the source of the conflict.

Conflicts are most likely to occur in response to a PUT request. For
example, if versioning were being used and the representation being
PUT included changes to a resource that conflict with those made by
an earlier (third-party) request, the origin server might use a 409
response to indicate that it can’t complete the request. In this
case, the response representation would likely contain information
useful for merging the differences based on the revision history.

6.5.9. 410 Gone

The 410 (Gone) status code indicates that access to the target
resource is no longer available at the origin server and that this
condition is likely to be permanent. If the origin server does not

Fielding & Reschke Standards Track [Page 60]

RFC 7231 HTTP/1.1 Semantics and Content June 2014

know, or has no facility to determine, whether or not the condition
is permanent, the status code 404 (Not Found) ought to be used
instead.

The 410 response is primarily intended to assist the task of web
maintenance by notifying the recipient that the resource is
intentionally unavailable and that the server owners desire that
remote links to that resource be removed. Such an event is common
for limited-time, promotional services and for resources belonging to
individuals no longer associated with the origin server’s site. It
is not necessary to mark all permanently unavailable resources as
“gone” or to keep the mark for any length of time — that is left to
the discretion of the server owner.

A 410 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]).

6.5.10. 411 Length Required

The 411 (Length Required) status code indicates that the server
refuses to accept the request without a defined Content-Length
(Section 3.3.2 of [RFC7230]). The client MAY repeat the request if
it adds a valid Content-Length header field containing the length of
the message body in the request message.

6.5.11. 413 Payload Too Large

The 413 (Payload Too Large) status code indicates that the server is
refusing to process a request because the request payload is larger
than the server is willing or able to process. The server MAY close
the connection to prevent the client from continuing the request.

If the condition is temporary, the server SHOULD generate a
Retry-After header field to indicate that it is temporary and after
what time the client MAY try again.

6.5.12. 414 URI Too Long

The 414 (URI Too Long) status code indicates that the server is
refusing to service the request because the request-target (Section
5.3 of [RFC7230]) is longer than the server is willing to interpret.
This rare condition is only likely to occur when a client has
improperly converted a POST request to a GET request with long query
information, when the client has descended into a “black hole” of
redirection (e.g., a redirected URI prefix that points to a suffix of
itself) or when the server is under attack by a client attempting to
exploit potential security holes.

Fielding & Reschke Standards Track [Page 61]

RFC 7231 HTTP/1.1 Semantics and Content June 2014

A 414 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]).

6.5.13. 415 Unsupported Media Type

The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource.
The format problem might be due to the request’s indicated
Content-Type or Content-Encoding, or as a result of inspecting the
data directly.

6.5.14. 417 Expectation Failed

The 417 (Expectation Failed) status code indicates that the
expectation given in the request’s Expect header field
(Section 5.1.1) could not be met by at least one of the inbound
servers.

6.5.15. 426 Upgrade Required

The 426 (Upgrade Required) status code indicates that the server
refuses to perform the request using the current protocol but might
be willing to do so after the client upgrades to a different
protocol. The server MUST send an Upgrade header field in a 426
response to indicate the required protocol(s) (Section 6.7 of
[RFC7230]).

Example:

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

This service requires use of the HTTP/3.0 protocol.

6.6. Server Error 5xx

The 5xx (Server Error) class of status code indicates that the server
is aware that it has erred or is incapable of performing the
requested method. Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent

Fielding & Reschke Standards Track [Page 62]

RFC 7231 HTTP/1.1 Semantics and Content June 2014

condition. A user agent SHOULD display any included representation
to the user. These response codes are applicable to any request
method.

6.6.1. 500 Internal Server Error

The 500 (Internal Server Error) status code indicates that the server
encountered an unexpected condition that prevented it from fulfilling
the request.

6.6.2. 501 Not Implemented

The 501 (Not Implemented) status code indicates that the server does
not support the functionality required to fulfill the request. This
is the appropriate response when the server does not recognize the
request method and is not capable of supporting it for any resource.

A 501 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]).

6.6.3. 502 Bad Gateway

The 502 (Bad Gateway) status code indicates that the server, while
acting as a gateway or proxy, received an invalid response from an
inbound server it accessed while attempting to fulfill the request.

6.6.4. 503 Service Unavailable

The 503 (Service Unavailable) status code indicates that the server
is currently unable to handle the request due to a temporary overload
or scheduled maintenance, which will likely be alleviated after some
delay. The server MAY send a Retry-After header field
(Section 7.1.3) to suggest an appropriate amount of time for the
client to wait before retrying the request.

Note: The existence of the 503 status code does not imply that a
server has to use it when becoming overloaded. Some servers might
simply refuse the connection.

6.6.5. 504 Gateway Timeout

The 504 (Gateway Timeout) status code indicates that the server,
while acting as a gateway or proxy, did not receive a timely response
from an upstream server it needed to access in order to complete the
request.