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

Иногда при попытке открыть страницу сайта возникает ошибка 502 Bad Gateway. Это происходит из-за того, что один сервер получает некорректный ответ от другого. Обычно с этим ничего нельзя сделать: проблема находится на стороне сайта. Однако в некоторых случаях дело может быть в вашем компьютере или сетевом оборудовании.

Ошибка 502 Bad Gateway возникает, когда сервер, к которому вы подключены, выступает в роли посредника, передающего информацию от другого сервера, и получает некорректный ответ. 502 — это код состояния HTTP, который использует сервер для описания ошибки.

Некорректные ответы могут поступать нескольким причинам.

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

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

  • HTTP Error 502 Bad Gateway;
  • HTTP 502;
  • 502 Service Temporarily Overloaded;
  • Temporary Error (502);
  • 502 Server Error: The server encountered a temporary error and could not complete your request;
  • 502 Bad Gateway Nginx.

В большинстве случаев ошибка происходит на стороне сервера, и вы никак не можете ее исправить. Тем не менее есть несколько способов.

Обновите страницу

Ошибка 502 часто бывает временной, поэтому достаточно просто обновить страницу. В большинстве браузеров сделать это можно с помощью клавиш Ctrl+R (Windows) или Cmd+R (Mac), а также с помощью кнопки «‎Обновить»‎, расположенной в адресной строке. Этот способ не всегда решает проблему, но попытка займет всего пару секунд.

Проверьте, работает ли сайт у других пользователей

Если вы не смогли получить доступ к сайту (по любой причине), можно проверить, столкнулись ли с такой проблемой другие люди. Для этого есть множество инструментов, например isitdownrightnow.com и downforeveryoneorjustme.com. Оба работают примерно одинаково: вводите адрес сайта, который нужно проверить, и получаете небольшой отчет.

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

Перейдите в другой браузер

Проблема, вызвавшая ошибку 502 Bad Gateway, может быть связана с браузером. Как это проверить? Просто воспользуйтесь другой программой — Google Chrome, Mozilla Firefox, Apple Safari или Microsoft Edge. Если ошибка не исчезла, значит, стоит попробовать другое решение.

Очистите кэш и файлы cookie в браузере

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

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

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

Проверьте плагины и расширения

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

Перезапустите устройства

Итак, вы уже выяснили, что сайт доступен для всех, кроме вас, а в другом браузере появляется та же ошибка. Значит, проблема находится на вашей стороне и дело не в браузере. Вполне возможно, что временные проблемы возникли с компьютером или сетевым оборудованием (Wi-Fi, роутер, модем и т. д.). Чтобы это исправить, можно попробовать перезапустить устройства.

Измените DNS-сервер

Иногда ошибку 502 вызывают проблемы с DNS-сервером. Можно попробовать его изменить — это не сложно. Как правило, DNS-сервер устанавливается интернет-провайдером. Вы можете изменить его на сторонний DNS-сервер, например OpenDNS или Google DNS.

Информационные

Upgrade:

RFC 8297 (Experimental)

Успешные

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

Сообщения о перенаправлениях

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

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

302 Found

POST

POST

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

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

draft-reschke-http-status-308

Клиентские

GET

HEAD

HTTP механизмы предварительного соединения

баг 634278

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

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

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

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

Range

Expect

Серверные

GET

HEAD

Retry-After:

Код состояния HTTP (англ. HTTP status code) — часть первой строки ответа сервера при запросах по протоколу HTTP.
Он представляет собой целое трёхразрядное десятичное число. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Примеры:

Читайте также:  Код ошибки 0x80070490 как исправить windows 10 почта

  • 201 Created.
  • 401 Unauthorized.
  • 507 Insufficient Storage.

Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода. В настоящее время выделено пять классов кодов состояния.

Веб-сервер Internet Information Services в своих файлах журналов, кроме стандартных кодов состояния, использует подкоды, записывая их через точку после основного. При этом в ответах от сервера данный подкод не размещается — он нужен администратору сервера, чтобы тот мог более точно определять источники проблем.

Обзорный списокПравить

Ниже представлен обзорный список всех описанных в данной статье кодов ответа:

Диаграмма принятия веб-сервером решений на основе заголовков

Статистика по кодам ответа, сгенерированная анализатором логов Webalizer

Описание кодовПравить


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

  • 100 Continue — сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.
  • 101 Switching Protocols — сервер выполняет требование клиента и переключает протоколы в соответствии с указанием, данным в поле заголовка Upgrade. Сервер отправляет заголовок ответа Upgrade, указывая протокол, на который он переключился. Появился в HTTP/1.1.
  • 102 Processing — запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.
  • 103 Early Hints — используется для раннего возврата части заголовков, когда заголовки полного ответа не могут быть быстро сформированы.


Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента.
В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.

  • 200 OK — успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.
  • 201 Created — в результате успешного выполнения запроса был создан новый ресурс. Сервер может указать адреса (их может быть несколько) созданного ресурса в теле ответа, при этом предпочтительный адрес указывается в заголовке Location. Серверу рекомендуется указывать в теле ответа характеристики созданного ресурса и его адреса, формат тела ответа определяется заголовком Content-Type. При обработке запроса новый ресурс должен быть создан до отправки ответа клиенту, иначе следует использовать ответ с кодом 202. Появился в HTTP/1.0.
  • 202 Accepted — запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.
  • 203 Non-Authoritative Information — аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.
  • 204 No Content — сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.
  • 205 Reset Content — сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.
  • 206 Partial Content — сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1. (подробнее…)
  • 207 Multi-Status — сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.
  • 208 Already Reported — члены привязки DAV уже были перечислены в предыдущей части (multistatus) ответа и не включаются снова.
  • 226 IM Used — заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.


Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям. Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.

Поведение клиентов при различных перенаправлениях описано в таблице:

  • 300 Multiple Choices — по указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.
  • 301 Moved Permanently — запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.
  • 302 Found, 302 Moved Temporarily — запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Некоторые[какие?] клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.
  • 303 See Other — документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с кодом 307 для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.
  • 304 Not Modified — сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.
  • 305 Use Proxy — запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.
  • 306 (зарезервировано) — использовавшийся в ранних версиях спецификации код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1). Согласно ранним наброскам, код означал Switch Proxy, указывая клиенту сменить используемый прокси-сервер на указанный сервером в заголовке ответа[18].
  • 307 Temporary Redirect — запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается. Например, POST-запрос должен быть отправлен по новому URI тем же методом POST. Этот код был введён вместе с 303-м вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).
  • 308 Permanent Redirect — запрашиваемый ресурс был окончательно перенесен на новый URI, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается. Например, POST-запрос должен быть отправлен по новому URI тем же методом POST. Этот код был введён вместо 301-го для избежания неоднозначности. Введено в RFC 7238 (RFC 7538).
Читайте также:  Switch код ошибки 2110 2003


Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

  • 400 Bad Request — сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.
  • 401 Unauthorized — для доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Иными словами, для доступа к запрашиваемому ресурсу клиент должен представиться, послав запрос, включив при этом в заголовок сообщения поле Authorization с требуемыми для аутентификации данными. Если запрос уже включает данные для авторизации, ответ 401 означает, что в авторизации с ними отказано.
  • 402 Payment Required — предполагается использовать в будущем[когда?]. В настоящий момент[когда?] не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

Сервер вернул ошибку 403 при попытке просмотра каталога «cgi-bin», доступ к которому был запрещён

Пример ошибки 502 Bad Gateway


Коды 5xx выделены под случаи необработанных исключений при выполнении операций на стороне сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

ТакжеПравить

ПримечанияПравить

  1. 1 2 2.2.6 449 «Retry With Status Code» // Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions. Архивная копия от 5 октября 2009 на Wayback Machine на сайте MSDN
  2. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 «6.1.1 Status Code and Reason Phrase Архивная копия от 7 июня 2018 на Wayback Machine» в RFC 2068
  3. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 RFC 2616. Дата обращения: 29 июля 2009. Архивировано 7 марта 2011 года.
  4. 1 2 3 IETF Draft WebDAV Advanced Collections Protocol — S.4.2.5. Дата обращения: 18 мая 2012. Архивировано 9 июля 2012 года.
  5. IETF Draft WebDAV Advanced Collections Protocol — S.10. Дата обращения: 18 мая 2012. Архивировано 9 июля 2012 года.
  6. rfc5842. Дата обращения: 12 сентября 2017. Архивировано 10 октября 2017 года.
  7. 1 2 3 4 5 6 7 8 9 10 RFC 2616 «10.3 Redirection 3xx» (стр. 61). Дата обращения: 29 июля 2009. Архивировано 7 марта 2011 года.
  8. rfc7538. Дата обращения: 12 сентября 2017. Архивировано 16 апреля 2015 года.
  9. IETF Draft WebDAV Advanced Collections Protocol — S.4.3.1.1. Дата обращения: 18 мая 2012. Архивировано 9 июля 2012 года.
  10. rfc7540. Дата обращения: 12 сентября 2017. Архивировано 23 июня 2015 года.
  11. 1 2 3 4 RFC 6585
  12. 1 2 IETF Draft A New HTTP Status Code to Report Legal Obstacles. Дата обращения: 6 марта 2013. Архивировано 22 мая 2013 года.
  13. RFC 2295 Transparent Content Negotiation in HTTP — S.8.1. Дата обращения: 18 мая 2012. Архивировано 8 июня 2012 года.
  14. IETF Draft WebDAV Advanced Collections Protocol — S.7.1. Дата обращения: 18 мая 2012. Архивировано 9 июля 2012 года.
  15. 1 2 3 4 5 6 7 Error Pages – CloudFlare Support. Дата обращения: 18 апреля 2016. Архивировано 4 марта 2016 года.
  16. RFC 2068 «10.3 Redirection 3xx» (стр. 56) Архивная копия от 7 июня 2018 на Wayback Machine.
  17. RFC 2616, раздел «10.3.3 302 Found», страница 63 Архивная копия от 7 марта 2011 на Wayback Machine.
  18. Josh Cohen HTTP/1.1 305 and 306 Response Codes Архивная копия от 8 сентября 2014 на Wayback Machine (англ.) // Netscape Communications Corp., 25 декабря 1996
  19. Что означает 403 Forbidden? Архивная копия от 21 февраля 2014 на Wayback Machine.
  20. Причины появления ошибки 404 Not Found Архивная копия от 21 февраля 2014 на Wayback Machine.
  21. RFC 2324 — Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0).
  22. draft-ietf-httpbis-legally-restricted-status-04. datatracker.ietf.org. Дата обращения: 22 декабря 2015. Архивировано 23 декабря 2015 года.
  23. Описание ошибки 500 Internal Server Error Архивная копия от 21 февраля 2014 на Wayback Machine.
  24. Resource Limit Reached. www.cloudlinux.com. Дата обращения: 21 июня 2022. Архивировано 15 мая 2021 года.
Читайте также:  Не удалось активировать виндовс 10 код ошибки 0x8007007b

СсылкиПравить

Основные документы по протоколу HTTP (по убыванию даты публикации)
  • Hypertext Transfer Protocol (HTTP) Status Code Registry . IANA (17 октября 2007). — реестр кодов состояния HTTP. Дата обращения: 30 июля 2009. Архивировано 17 февраля 2012 года.
  • RFC 2616 Draft standard «Hypertext Transfer Protocol — HTTP/1.1» (англ.) (с  «Протокол передачи гипертекста — HTTP/1.1»); IETF, июнь 1999; Fielding Roy (), Gettys Jim (Compaq/W3C), Mogul J. (Compaq), (MIT/W3C), Masinter L. (Xerox), Leach P. (Microsoft), Berners-Lee Tim (W3C/MIT)  — обновление протокола HTTP версии 1.1.
  • RFC 2068 Proposed standard «Hypertext Transfer Protocol — HTTP/1.1» (англ.) (с  «Протокол передачи гипертекста — HTTP/1.1»); IETF, январь 1997; Fielding Roy (), Gettys Jim (DEC), Mogul J. (DEC), (MIT/LCS), Berners-Lee Tim (MIT/LCS) — ранняя спецификация по HTTP версии 1.1.
  • RFC 1945 Informational «Hypertext Transfer Protocol — HTTP/1.0» (англ.) (с  «Протокол передачи гипертекста — HTTP/1.0»); IETF, май 1996; Berners-Lee Tim (MIT/LCS), Fielding Roy (), (MIT/LCS) — самая первая спецификация по протоколу HTTP. Так же включает в себя описание HTTP/0.9.
Документы по расширениям и обновлениям протокола HTTP (по убыванию даты публикации)
  • RFC 4918 Proposed Standard «HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)» (англ.) (с  «Расширения HTTP для распределённой авторской работы и управления версиями через веб (WebDAV)»); IETF, июнь 2007; Dusseault Ed. L. () — поздняя спецификация по протоколу WebDAV, заместившая RFC 2518.
  • RFC 3229 Proposed standard «Delta encoding in HTTP» (англ.) (с  «Дельта-кодирование в HTTP»); IETF, январь 2002; Mogul J. (Compaq WRL), Krishnamurthy B. (AT&T), Douglis F. (AT&T), Feldmann A. (Univ. of Saarbrücken), Goland Y. (Marimba), van Hoff A. (Marimba), Hellerstein D. (ERS/USDA).
  • RFC 2817 Proposed Standard «Upgrading to TLS Within HTTP/1.1» (англ.) (с  «Обновление к TLS совместно с HTTP/1.1»); IETF, май 2000; (4K Associates/), Lawrence S. (Agranat Systems, Inc.) — обновление к RFC 2616 для описания работы HTTP и TLS.
  • RFC 2774 Experimental «An HTTP Extension Framework» (англ.) (с  «Каркас расширений HTTP»); IETF, февраль 2000; Nielsen H. (Microsoft), Leach P. (Microsoft), Lawrence S. (Agranat Systems).
  • Internet Draft «WebDAV Advanced Collections Protocol» (с  «Протокол продвинутых коллекций WebDAV»); IETF, 18 июня 1999; Slein J. (Xerox), Whitehead Jr. E. J. (), Davis J. (CourseNet), Clemm G. (Rational), Fay C. (), Crawford J. (IBM), Chihaya T. (DataChannel)  — управление коллекциями в WebDAV; просрочился 18 декабря 1999 года.
  • RFC 2518 Proposed Standard «HTTP Extensions for Distributed Authoring — WEBDAV» (англ.) (с  «Расширения HTTP для распределённой авторской работы — WEBDAV»); IETF, февраль 1999; Goland Y. (Microsoft), Whitehead E. (), Faizi A. (Netscape), Carter S. (Novell), Jensen D. (Novell) — первая спецификация по протоколу WebDAV (замещена RFC 4918).
  • RFC 2295 Experimental «Transparent Content Negotiation in HTTP» (англ.) (с  «Прозрачное согласование содержимого в HTTP»); IETF, март 1998; Holtman K. (TUE), Mutz A. (Hewlett-Packard).
Дополнительные материалы
  • Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions . Microsoft (14 марта 2007). — описание поддержки клиентских расширений в протоколе WebDAV. Дата обращения: 30 июля 2009. Архивировано 17 февраля 2012 года.
  • RFC 2324 Informational «Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)» (англ.) (с  «Гипертекстовый протокол управления кофеваркой (HTCPCP/1.0)»); IETF, 1 апреля 1998; Masinter L..
  • KB 318380 Коды состояния служб IIS. Microsoft (4 декабря 2007). — список расширенных кодов состояния для протоколов HTTP и FTP. Дата обращения: 16 января 2010. Архивировано 17 февраля 2012 года.
  • Справочник по кодам статуса HTTP. Яндекс. — обработка кодов состояния HTTP роботами Яндекса. Дата обращения: 2 мая 2018.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *