Server error expired request

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

Информационные 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

This document identifies some of the error codes and messages that Google APIs return. Specifically, the errors listed here are in the global, or default, domain for Google APIs. Many APIs also define their own domains, which identify API-specific errors that are not in the global domain. For those errors, the value of the domain property in the JSON response will be an API-specific value, such as youtube.parameter.

This page lists errors by their HTTP status codes as defined in RFC 7231.

The sample JSON response below demonstrates how a global error is communicated:

{
 "error": {
  "errors": [
   {
    "domain": "global",
    "reason": "invalidParameter",
    "message": "Invalid string value: 'asdf'. Allowed values: [mostpopular]",
    "locationType": "parameter",
    "location": "chart"
   }
  ],
  "code": 400,
  "message": "Invalid string value: 'asdf'. Allowed values: [mostpopular]"
 }
}

Errors

1. MOVED_PERMANENTLY (301)
2. SEE_OTHER (303)
3. NOT_MODIFIED (304)
4. TEMPORARY_REDIRECT (307)
5. BAD_REQUEST (400)
6. UNAUTHORIZED (401)
7. PAYMENT_REQUIRED (402)
8. FORBIDDEN (403)
9. NOT_FOUND (404)
10. METHOD_NOT_ALLOWED (405)
11. CONFLICT (409)
12. GONE (410)
13. PRECONDITION_FAILED (412)
14. REQUEST_ENTITY_TOO_LARGE (413)
15. REQUESTED_RANGE_NOT_SATISFIABLE (416)
16. EXPECTATION_FAILED (417)
17. PRECONDITION_REQUIRED (428)
18. TOO_MANY_REQUESTS (429)
19. INTERNAL_SERVER_ERROR (500)
20. NOT_IMPLEMENTED (501)
21. SERVICE_UNAVAILABLE (503)

MOVED_PERMANENTLY (301)

Error code	Description
movedPermanently	This request and future requests for the same operation have to be sent to the URL specified in the Location header of this response instead of to the URL to which this request was sent.

SEE_OTHER (303)

Error code	Description
seeOther	Your request was processed successfully. To obtain your response, send a GET request to the URL specified in the Location header.
mediaDownloadRedirect	Your request was processed successfully. To obtain your response, send a GET request to the URL specified in the Location header.

NOT_MODIFIED (304)

Error code	Description
notModified	The condition set for an If-None-Match header was not met. This response indicates that the requested document has not been modified and that a cached response should be retrieved. Check the value of the If-None-Match HTTP request header.

TEMPORARY_REDIRECT (307)

Error code	Description
temporaryRedirect	To have your request processed, resend it to the URL specified in the Location header of this response.

BAD_REQUEST (400)

Error code	Description
badRequest	The API request is invalid or improperly formed. Consequently, the API server could not understand the request.
badBinaryDomainRequest	The binary domain request is invalid.
badContent	The content type of the request data or the content type of a part of a multipart request is not supported.
badLockedDomainRequest	The locked domain request is invalid.
corsRequestWithXOrigin	The CORS request contains an XD3 X-Origin header, which is indicative of a bad CORS request.
endpointConstraintMismatch	The request failed because it did not match the specified API. Check the value of the URL path to make sure it is correct.
invalid	The request failed because it contained an invalid value. The value could be a parameter value, a header value, or a property value.
invalidAltValue	The alt parameter value specifies an unknown output format.
invalidHeader	The request failed because it contained an invalid header.
invalidParameter	The request failed because it contained an invalid parameter or parameter value. Review the API documentation to determine which parameters are valid for your request.
invalidQuery	The request is invalid. Check the API documentation to determine what parameters are supported for the request and to see if the request contains an invalid combination of parameters or an invalid parameter value. Check the value of the q request parameter.
keyExpired	The API key provided in the request expired, which means the API server is unable to check the quota limit for the application making the request. Check the Google Developers Console for more information or to obtain a new key.
keyInvalid	The API key provided in the request is invalid, which means the API server is unable to check the quota limit for the application making the request. Use the Google Developers Console to find your API key or to obtain one.
lockedDomainCreationFailure	The OAuth token was received in the query string, which this API forbids for response formats other than JSON or XML. If possible, try sending the OAuth token in the Authorization header instead.
notDownload	Only media downloads requests can be sent to /download/* URL paths. Resend the request to the same path, but without the /download prefix.
notUpload	The request failed because it is not an upload request, and only upload requests can be sent to /upload/* URIs. Try resending the request to the same path, but without the /upload prefix.
parseError	The API server cannot parse the request body.
required	The API request is missing required information. The required information could be a parameter or resource property.
tooManyParts	The multipart request failed because it contains too many parts
unknownApi	The API that the request is calling is not recognized.
unsupportedMediaProtocol	The client is using an unsupported media protocol.
unsupportedOutputFormat	The alt parameter value specifies an output format that is not supported for this service. Check the value of the alt request parameter.
wrongUrlForUpload	The request is an upload request, but it failed because it was not sent to the proper URI. Upload requests must be sent to URIs that contain the /upload/* prefix. Try resending the request to the same path, but with the /upload prefix.

Error code	Description
unauthorized	The user is not authorized to make the request.
authError	The authorization credentials provided for the request are invalid. Check the value of the Authorization HTTP request header.
expired	Session Expired. Check the value of the Authorization HTTP request header.
lockedDomainExpired	The request failed because a previously valid locked domain has expired.
required	The user must be logged in to make this API request. Check the value of the Authorization HTTP request header.

PAYMENT_REQUIRED (402)

Error code	Description
dailyLimitExceeded402	A daily budget limit set by the developer has been reached.
quotaExceeded402	The requested operation requires more resources than the quota allows. Payment is required to complete the operation.
user402	The requested operation requires some kind of payment from the authenticated user.

FORBIDDEN (403)

Error code	Description
forbidden	The requested operation is forbidden and cannot be completed.
accessNotConfigured	Your project is not configured to access this API. Please use the Google Developers Console to activate the API for your project.
accessNotConfigured	The project has been blocked due to abuse. See http://support.google.com/code/go/developer_compliance.
accessNotConfigured	The project has been marked for deletion.
accountDeleted	The user account associated with the request’s authorization credentials has been deleted. Check the value of the Authorization HTTP request header.
accountDisabled	The user account associated with the request’s authorization credentials has been disabled. Check the value of the Authorization HTTP request header.
accountUnverified	The email address for the user making the request has not been verified. Check the value of the Authorization HTTP request header.
concurrentLimitExceeded	The request failed because a concurrent usage limit has been reached.
dailyLimitExceeded	A daily quota limit for the API has been reached.
dailyLimitExceeded	The daily quota limit has been reached, and the project has been blocked due to abuse. See the Google APIs compliance support form to help resolve the issue.
dailyLimitExceededUnreg	The request failed because a daily limit for unauthenticated API use has been hit. Continued use of the API requires signup through the Google Developers Console.
downloadServiceForbidden	The API does not support a download service.
insufficientAudience	The request cannot be completed for this audience.
insufficientAuthorizedParty	The request cannot be completed for this application.
insufficientPermissions	The authenticated user does not have sufficient permissions to execute this request.
limitExceeded	The request cannot be completed due to access or rate limitations.
lockedDomainForbidden	This API does not support locked domains.
quotaExceeded	The requested operation requires more resources than the quota allows.
rateLimitExceeded	Too many requests have been sent within a given time span.
rateLimitExceededUnreg	A rate limit has been exceeded and you must register your application to be able to continue calling the API. Please sign up using the Google Developers Console.
responseTooLarge	The requested resource is too large to return.
servingLimitExceeded	The overall rate limit specified for the API has already been reached.
sslRequired	SSL is required to perform this operation.
unknownAuth	The API server does not recognize the authorization scheme used for the request. Check the value of the Authorization HTTP request header.
userRateLimitExceeded	The request failed because a per-user rate limit has been reached.
userRateLimitExceededUnreg	The request failed because a per-user rate limit has been reached, and the client developer was not identified in the request. Please use the Google Developer Console (https://console.developers.google.com) to create a project for your application.
variableTermExpiredDailyExceeded	The request failed because a variable term quota expired and a daily limit was reached.
variableTermLimitExceeded	The request failed because a variable term quota limit was reached.

NOT_FOUND (404)

Error code	Description
notFound	The requested operation failed because a resource associated with the request could not be found.
notFound	A resource associated with the request could not be found. If you have not used this API in the last two weeks, please re-deploy the App Engine app and try calling it again.
unsupportedProtocol	The protocol used in the request is not supported.

METHOD_NOT_ALLOWED (405)

Error code	Description
httpMethodNotAllowed	The HTTP method associated with the request is not supported.

CONFLICT (409)

Error code	Description
conflict	The API request cannot be completed because the requested operation would conflict with an existing item. For example, a request that tries to create a duplicate item would create a conflict, though duplicate items are typically identified with more specific errors.
duplicate	The requested operation failed because it tried to create a resource that already exists.

GONE (410)

Error code	Description
deleted	The request failed because the resource associated with the request has been deleted

PRECONDITION_FAILED (412)

Error code	Description
conditionNotMet	The condition set in the request’s If-Match or If-None-Match HTTP request header was not met. See the ETag section of the HTTP specification for details. Check the value of the If-Match HTTP request header.

REQUEST_ENTITY_TOO_LARGE (413)

Error code	Description
backendRequestTooLarge	The request is too large.
batchSizeTooLarge	The batch request contains too many elements.
uploadTooLarge	The request failed because the data sent in the request is too large.

REQUESTED_RANGE_NOT_SATISFIABLE (416)

Error code	Description
requestedRangeNotSatisfiable	The request specified a range that cannot be satisfied.

EXPECTATION_FAILED (417)

Error code	Description
expectationFailed	A client expectation cannot be met by the server.

PRECONDITION_REQUIRED (428)

Error code	Description
preconditionRequired	The request requires a precondition that is not provided. For this request to succeed, you need to provide either an If-Match or If-None-Match header with the request.

TOO_MANY_REQUESTS (429)

Error code	Description
rateLimitExceeded	Too many requests have been sent within a given time span.

INTERNAL_SERVER_ERROR (500)

Error code	Description
internalError	The request failed due to an internal error.

NOT_IMPLEMENTED (501)

Error code	Description
notImplemented	The requested operation has not been implemented.
unsupportedMethod	The request failed because it is trying to execute an unknown method or operation.

SERVICE_UNAVAILABLE (503)

Error code	Description
backendError	A backend error occurred.
backendNotConnected	The request failed due to a connection error.
notReady	The API server is not ready to accept requests.

You’re viewing Apigee Edge documentation.
View
Apigee X documentation.

Videos

Watch the following videos to learn more about solving 500 Internal Server Errors.

Video	Description
Introduction	Provides an introduction to 500 Internal Server Errors and possible causes. Also demonstrates a real time 500 Internal Server error along with steps to troubleshoot and resolve the error.
Handle Service Callout and Extract Variable errors	Demonstrates two 500 Internal Server Errors caused by Service Callout and Extract Variable policies and shows how to troubleshoot and resolve these errors.
Handle JavaScript policy errors	Shows a 500 Internal Server Error caused by a JavaScript policy and the steps to troubleshoot and resolve this error.
Handle failures from backend servers	Shows example 500 Internal Server Errors caused by a failure in backend server and shows steps to resolve the errors.

Symptom

The client application gets an HTTP status code of 500 with the message
«Internal Server Error» as a response for API calls. The 500 Internal Server
error could be caused by an error during the execution of any policy within Edge or by an error
on the target/backend server.

The HTTP status code 500 is a generic error response. It means that the server encountered an
unexpected condition that prevented it from fulfilling the request. This error is usually
returned by the server when no other error code is suitable.

Error Messages

You may get the following error message:

HTTP/1.1 500 Internal Server Error

In some cases, you may observe another error message which has more details. Here is a sample
error message:

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

Possible Causes

The 500 Internal Server Error could be thrown due to a number of different causes. In Edge,
the causes can be classified into two main categories based on where the error occurred:

Cause	Details	Detailed Troubleshooting Steps are Provided For
Execution Error in an Edge Policy	A Policy within the API proxy may fail for some reason.	Edge Private and Public Cloud users
Error in the Backend Server	The backend server may fail for some reason.	Edge Private and Public Cloud users

Execution Error in an Edge Policy

A Policy within
the API proxy may fail for some reason. This section explains how to troubleshoot the issue if
the 500 Internal Server Error occurs during the execution of a policy.

Diagnosis

Diagnostic Steps for Private and Public Cloud Users

If you have the trace UI session for the error, then:

1. Verify that the error was caused by the execution of a policy. See Determining the source of the problem for details.
2. If the error occurred during policy execution, continue.. If the error was caused by the
   backend server, go to Error in the Backend Server.
3. Select the API request that is failing with 500 Internal Server Error in the trace.
4. Examine the request and select the specific policy that has failed or the flow named
   «Error» that is immediately following the failed policy in the trace.
5. Get more details about the error either by checking the «error» field under the Properties
   section or the Error content.
6. Using the details you’ve collected about the error, try to determine its cause.

Diagnostic Steps for Private Cloud Users Only

If you don’t have the trace UI session, then:

1. Verify that the error occurred during the execution of a policy. See Determining the source of the problem for details.
2. If the error was caused by policy execution, continue. If the error occurred during policy
   execution, continue. If the error was caused by the backend server, go to Error in the Backend Server.
3. Use the NGINX access logs as explained in Determining
   the source of the problem to determine the failing policy in the API proxy and also the
   unique request message id
4. Check the Message Processor logs
   (/opt/apigee/var/log/edge-message-processor/logs/system.log) and search for the
   unique request message id in it.
5. If you do find the unique request message ID, see if you can get more information about the
   cause for the failure.

Resolution

If you have determined the cause of the issue with the policy, try to correct the problem by
fixing the policy and redeploying the proxy.

The following examples illustrate how to determine the cause and resolution for different
types of issues.

If you need further assistance in troubleshooting 500 Internal Server Error or you suspect
that it’s an issue within Edge, contact Apigee
Support.

Example 1: Failure in Service Callout policy due to an error in the backend
server

If the call to the backend server fails within the Service Callout policy with any error such
as 4XX or 5XX, then it will be treated as 500 Internal Server Error.

1. Here’s an example where the backend service fails with a 404 error within the Service
   Callout policy. The following error message is sent to the end user:

   {
   "fault":
        { "detail":
              { "errorcode":"steps.servicecallout.ExecutionFailed"
              },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
    failed. Reason: ResponseCode 404 is treated as error"
             }
        }
   }
   

2. The following trace UI session shows 500 status code caused due to an error in Service
   Callout policy:

   

3. In this example, the «error» property lists the reason for the Service Callout policy
   failure as «ResponseCode 404 is treated as error». This error might occur if
   the resource being accessed via the backend server URL in the Service Callout policy is not
   available.
4. Check the availability of the resource on the backend server. It might not be available
   temporarily/permanently or it might have been moved to a different location.

Example 1 Resolution

1. Check the availability of the resource on the backend server. It might not be available
   temporarily/permanently or it might have been moved to a different location.
2. Fix the backend server URL in the Service Callout policy to point to a valid and existing
   resource.
3. If the resource is only temporarily unavailable, then try making the API request once the
   resource is available.

Let’s now look at another example, where 500 Internal Server Error is caused due to an error
in the Extract Variables policy and see how to troubleshoot and resolve the issue.

1. The following trace in UI session shows 500 status code due to an error in Extract
   Variables policy:

   

2. Select the failing Extract Variables policy, scroll down and look at the «Error
   Content» section for more details:

   

3. The Error Content indicates that
   the«serviceCallout.oamCookieValidationResponse» variable is not available in
   the Extract Variables policy. As the name of the variable indicates, it should be holding the
   response of the preceding Service Callout policy.
4. Select the Service Callout policy in the trace and you might find that the
   «serviceCallout.oamCookieValidationResponse» variable was not set. This
   indicates that the call to the backend service failed, resulting in an empty response
   variable.
5. Though the Service Callout policy has failed, the execution of the policies after Service
   Callout policy continue because the «continueOnError» flag in the Service Callout policy is set
   to true, as shown below:

   <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
     <DisplayName>Callout.OamCookieValidation</DisplayName>
     <Properties />
     <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
       <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
     </Request>
     <Response>serviceCallout.oamCookieValidationResponse</Response>
     <HTTPTargetConnection>
       <Properties />
       <URL>http://{Url}</URL>
     </HTTPTargetConnection>
   </ServiceCallout>
   

6. Note the unique message id «X-Apigee.Message-ID» for this specific API
   request from the trace, as follows:
   1. Select the «Analytics Data Recorded» phase from the request.
   2. Scroll down and note the value of X-Apigee.Message-ID.

   

7. View the Message Processor log
   (/opt/apigee/var/log/edge-message-processor/system.log) and search for the unique
   message id noted down in step #6. The following error message was observed for the specific API
   request:

   2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX
   

   The above error indicates that the Service Callout policy failed due to a connection
   timeout error while connecting to the backend server.

8. To determine the cause for the connection timeout error, executed the
   telnet command to the backend server from the Message Processor(s). The telnet
   command gave «Connection timed out» error as shown below:

   telnet mybackend.domain.com 443
   Trying XX.XX.XX.XX...
   telnet: connect to address XX.XX.XX.XX: Connection timed out
   

   Typically, this error is observed under the following circumstances:

   • When the backend server is not configured to allow traffic from the Edge Message
     Processors.
   • If the backend server is not listening on the specific port.

   In the above illustrated example, though the Extract Variables policy failed, the actual
   cause was that Edge was unable to connect to the backend server in the Service Callout
   policy. And the cause for this failure was that the backend end server was not configured to
   allow traffic from the Edge Message Processors.

   Your own Extract Variables policy will behave differently and may fail for a different
   reason. You can troubleshoot the issue appropriately depending on the cause for failure of
   your Extract Variables policy by checking the message in the error
   property.

Example 2 Resolution

1. Fix the cause for error or failure in Extract Variables policy appropriately.
2. In the illustrated example above, the solution was to rectify the network configuration to
   allow the traffic from Edge Message Processors to your backend server. This was done by
   allowlisting the Message Processors’ IP addresses on the specific backend server. For example,
   on Linux, you could use iptables to allow the traffic from
   Message Processor’s IP addresses on the backend server.

Example 3: Failure in JavaCallout policy

Let’s now look at one more example, where 500 Internal Server Error is caused due to an error
in Java Callout policy and see how to troubleshoot and resolve the issue.

1. The following UI trace shows 500 status code due to an error in Java Callout Policy:

   

2. Select the Flow named «Error» followed by the failed Java Callout Policy
   to get the error details as shown in the figure below:

   

3. In this example, the «error» property under the Properties section reveals
   that the failure is due to expired password being used while connecting to the Oracle Database
   from within the JavaCallout policy. Your own Java callout will behave differently and will
   populate a different message in the error property.
4. Check the JavaCallout policy code and confirm the correct configuration that needs to be
   used.

Example 3 Resolution

Fix the Java callout code or configuration appropriately to avoid the runtime exception. In
the illustrated Java callout failure example above, one would need to use the correct password
for connecting to the Oracle database to resolve the issue.

Error in the Backend Server

A 500 Internal Server Error could also originate from the backend server. This section
explains how to troubleshoot the issue if the error comes from the backend server.

Diagnosis

Diagnostic Steps for All Users

The cause of other backend errors can vary widely. You will need to diagnose each situation
independently.

1. Verify that the error was caused by the backend server. See Determining the source of the problem for details.
2. If the error was caused by the backend server, continue. If the error occurred during
   policy execution, go to Execution Error in Edge
   Policy.
3. Follow the steps below depending on whether or not you have access to a Trace session for
   the failed API, or if the backend is a Node.js server:

If you do not have a Trace session for the failed API call:

1. If the UI trace is not available for the failing request, then check the backend server
   logs to get details about the error.
2. If possible, enable the debug mode on the backend server to get more details about the
   error and the cause.

If you do have a Trace session for the failed API call:

If you have a Trace session, then the following steps will help you diagnose the problem.

1. In the Trace tool, select the API request that has failed with 500 Internal Server
   Error.
2. Select the «Response received from target server» phase from the failing
   API request as shown in the figure below:

   

3. Check the «Response Content» section to get details about the error.

   

4. In this example, the Response Content which is a SOAP Envelope, shows the fault string as
   «Not Authorized» message. The most likely cause for this
   issue is that the proper credentials (username/password, access token, etc.) are not passed to
   the backend server by the user. This issue can be fixed by passing the correct credentials to
   the backend server.

If the backend is a Node.js server:

1. If the backend is a Node.js Backend Server, then check the Node.js logs
   for the specific API Proxy in the Edge UI (both Public and Private Cloud users can
   check the Node.js logs). If you are an Edge Private Cloud user, you
   can also check your Message Processor logs
   (/opt/apigee/var/log/edge-message-processor/logs/system.log) for more details
   about the error.

   NodeJS Logs option in the Edge UI — Overview Tab of API Proxy

   

Resolution

1. Once you’ve identified the cause of the error, fix the issue in your backend server.
2. If it’s a Node.js backend server:
   1. Check if the error is thrown from your custom code and fix the issue, if possible.
   2. If the error is not thrown from your custom code or if you need assistance, contact
      Apigee Support.

If you need further assistance in troubleshooting 500 Internal Server Error or you suspect
that it’s an issue within Edge, contact Apigee
Support.

Determining the source of the problem

Use one of the following procedures to determine if the 500 Internal Server Error was thrown
during the execution of a policy within the API proxy or by the backend server.

Using Trace in UI

Note: The steps in this section can be performed by both Public and
Private Cloud users.

1. If the issue is still active, enable the trace in UI for the affected API.
2. Once you have captured the trace, select the API request that shows the response code as
   500.
3. Navigate through all the phases of the failing API request and check which phase returns
   the 500 Internal Server Error:
   1. If the error is thrown during the execution of a policy, then proceed to Execution Error in an Edge Policy.
   2. If the backend server has responded with 500 Internal Server, then proceed to Error in the Backend Server.

Using API Monitoring

Note: The steps in this section can be performed by Public Cloud users only.

API Monitoring enables you to isolate problem areas quickly to diagnose error, performance, and latency issues and their source,
such as developer apps, API proxies, backend targets, or the API platform.

Step through a sample scenario that demonstrates how to troubleshoot 5xx issues with your APIs using API Monitoring.
For example, you may want to set up an alert to be notified when the number of 500 status codes or steps.servicecallout.ExecutionFailed faults exceeds a particular threshold.

Using NGINX Access
Logs

Note: The steps in this section are for Edge Private Cloud users
only.

You can also refer to NGINX Access logs to determine whether the 500 status code was thrown
during the execution of a policy within the API proxy or by the backend server. This is
particularly useful if the issue has occurred in the past or if the issue is intermittent and you
are unable to capture the trace in UI. Use the following steps to determine this information from
NGINX access logs:

1. Check the NGINX access logs (/opt/apigee/var/log/edge-router/nginx/ <org>~
<env>.<port#>_access_log ).
2. Search if there are any 500 Errors for the specific API proxy at the specific
   duration.
3. If there are any 500 Errors, then check if the error is a policy or a target server error,
   as shown below:

   Sample Entry showing a Policy Error

   

   Sample Entry showing a Target Server Error

   

4. Once you’ve identified whether it is a policy or target server error:
   1. Proceed to Execution Error in an Edge Policy if
      it is a policy error.
   2. Proceed to Error in Backend Server if it is a target
      server error.

Что означает код ошибки 500

Ошибка 500 (Internal Server Error) — это внутренняя проблема сервера. Она возникает, когда браузер или другой клиент отправляет серверу запрос, а тот не может его обработать.

Одна из самых частых причин появления ошибки 500 — это неправильный синтаксис файла .htaccess. Кроме того, она порой возникает после загрузки на сервер неверных CGI‑скриптов или установки некорректных прав доступа.

То есть в ошибке 500, как и в других ответах с кодом, который начинается на цифру 5, виноваты разработчики или администраторы сервера. Но никак не пользователи.

Что делать пользователю при ошибке 500

Если вы увидели ошибку 500 на чужом сайте, есть два варианта.

Подождать

Если у вас нет доступа к этому ресурсу, вы не сможете отредактировать файл, изменить настройки или выполнить другие подобные действия. Поэтому стоит подождать, пока администратор исправит ошибку, и зайти на сайт позднее.

Сообщить администратору ресурса

Не все владельцы сайтов круглосуточно мониторят логи и читают сообщения об ошибках. Вполне возможно, что администратор просто не в курсе, что сайт перестал работать.

В таком случае вы можете помочь. Попробуйте найти контактную информацию и связаться с владельцем ресурса, чтобы сообщить о проблеме. Если на самом сайте из‑за ошибки 500 вы никаких полезных данных не видите, найдите сохранённую копию страницы в поисковиках или в архиве интернета.

Что при ошибке 500 пользователю делать бессмысленно

Так как проблема связана с сервером, то нет резона что‑то предпринимать со стороны клиента. Поэтому не пытайтесь:

• перезагружать компьютер;
• менять браузер;
• переустанавливать ПО;
• перезагружать роутер.

Что делать администратору при ошибке 500

Конечно, многое зависит от специфики вашего ресурса: на каком движке он работает, на каком хостинге располагается и что вы меняли на сайте в последнее время. Но всё же универсальные рекомендации в большинстве случаев помогают избавиться от ошибки 500.

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

Проверить синтаксис файла .htaccess

Если вы используете веб‑сервер Apache, то в корне вашего сайта или во вложенных папках, скорее всего, есть файл .htaccess. В нём хранятся серверные настройки.

В большинстве случаев ресурс будет работать и без этого файла. Попробуйте переименовать .htaccess, например, в .htaccess_, а затем снова зайти на главную страницу сайта.

Если ошибка 500 исчезла, значит, дело именно в .htaccess. Проверьте синтаксис этого файла — возможно, при редактировании вы где‑то вставили лишний символ или допустили опечатку. Если есть предыдущая версия настроек, верните её и посмотрите, появляется ли ошибка 500.

Иногда помогает закомментировать строку Options в .htaccess — вставить # в самом её начале. Если это не сработало, закомментируйте и другие строки, а затем последовательно убирайте #, чтобы найти проблемное место в файле.

Если вы отредактировали .htaccess, проверьте, сохранились ли изменения. Бывает, что хостер выставляет на этот файл права, которые запрещают редактирование. В таком случае попробуйте скачать .htaccess к себе на компьютер, изменить файл в любом текстовом редакторе и залить на сайт вместо старой версии.

Посмотреть лог ошибок

Если вы недавно проводили какие‑то работы на сайте, возможно, это привело к ошибке 500. Откройте логи и посмотрите, нет ли там сообщений о проблемах. Если есть, проанализируйте их и попробуйте отменить последние корректировки.

Хостеры обычно указывают, где по умолчанию хранятся логи и как получить к ним доступ из панели управления. Эти сведения можно найти в разделах помощи или FAQ (frequently asked questions — часто задаваемые вопросы) на сайте хостинга.

Выставить права для CGI‑скриптов

Если вы используете CGI‑скрипты, то сами файлы с ними и папки, в которых они лежат, должны иметь право доступа 0755 (drwxr‑xr‑x). Такая комбинация разрешает запись в них только для владельца. Остальные пользователи могут лишь читать эти файлы и запускать их.

Если у вас установлены другие права доступа, это может приводить к ошибке 500.

Проверить содержимое CGI‑скриптов

Корректные CGI‑скрипты должны иметь окончания строк в формате Unix (n), а не в формате Windows (rn). Чтобы сохранить правильный вариант, загружать код на большинство хостингов нужно по FTP в режиме ASCII. Если вы не знаете, какие настройки использовали, перезалейте скрипты и посмотрите, не исчезла ли ошибка 500.

Также CGI‑программы могут формировать неправильные HTTP‑заголовки ответа. В этом случае вы, скорее всего, увидите ошибки в логах.

Удалить или отключить недавно установленные плагины или компоненты

Бывает, что отдельные компоненты сайта или плагины конфликтуют между собой. Это также приводит к ошибке 500 и другим проблемам на стороне сервера.

Если вы недавно устанавливали модули либо обновляли их, попробуйте отключить эти элементы в панели администрирования. Возможно, после этого на сайте возникнут другие ошибки. Но если ответ 500 больше не приходит, дело как раз в конфликте компонентов или плагинов.

Оптимизировать скрипты

Если скрипты выполняются долго или для них не хватает ресурсов, попробуйте пересмотреть их содержимое. Возможно, код нуждается в оптимизации, чтобы он потреблял меньше процессорного времени и оперативной памяти.

Особенно часто скриптам не хватает ресурсов, если вы используете виртуальный хостинг. Там количество памяти жёстко ограничено, чтобы у всех аккаунтов в рамках одного физического сервера были равные возможности.

Попробуйте разбить скрипт на блоки и оценить эффективность работы каждого из них. Если в коде много внешних вызовов или потребление памяти стабильно растёт вплоть до установленного лимита, с этим точно стоит что‑то сделать.

Увеличить объём оперативной памяти сервера

Бывает, что даже после оптимизации скриптов они всё равно потребляют слишком много памяти. В этом случае придётся перейти на более дорогой пакет обслуживания на хостинге или, если предоставляется такая возможность, увеличить непосредственно выделение памяти. И не переплачивать за другие ресурсы, которые вам не нужны.

Попросить помощи

Обратитесь в службу поддержки хостера или на профильный форум. Поищите похожие ошибки на Stack Overflow — если там нет подходящей темы, создайте новую. Опишите ситуацию как можно более детально и будьте готовы пробовать различные варианты, которые вам предложат в комментариях.

Правда, порой ответов приходится ждать долго. Поэтому имеет смысл зайти в похожие темы и попросить помощи там.

Наконец, можно зарегистрироваться на сайтах для фрилансеров в качестве заказчика. Специалисты помогут вам решить проблему, пусть и не бесплатно.

Читайте также 💿⚙️💻

• Что делать, если тормозит браузер
• Как исправить ошибку CPU Fan Error при загрузке компьютера
• Что делать, если DNS-сервер не отвечает
• Что означает 404 Not Found и другие ошибки веб-страниц
• Что делать, если пропал интернет на Windows