Status code 302

HTTP протокол: основные правила Интернета, которые должен знать каждый веб-разработчик. Как браузер взаимодействует с сервером.

HTTP коды состояния перенаправления: 300, 301, 302, 303, 304, 305, 306, 307

Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике серверы и протоколы и ее разделе HTTP протокол. Данная публикация будет о HTTP кодах состояния перенаправления. К HTTP кодам перенаправления относятся следующие коды: 300, 301, 302, 303, 304, 305, 306, 307. Напомню, что коды перенаправления говорят клиенту о том, что для успешного завершения запроса необходимо выполнить какое-то действие. Обычно браузеры выполняют такие действия без вмешательства пользователя. В данной записи мы рассмотрим сперва все HTTP коды перенаправления, а затем рассмотрим каждый код в отдельности более подробно.

HTTP коды состояния перенаправления: 300, 301, 302, 303, 304, 305, 306, 307

Общая информации о HTTP кодах перенаправления

Если вы хотите узнать всё про протокол HTTP, обратитесь к навигации по рубрике HTTP протокол. Да, эти коды состояния, как раз и есть тот самый Redirect 301 или склейка доменов, глупое выражение: Redirect 301 – склейка домена. Автор тоже этим грешил, автор каится и обещает исправиться. Все дело в том, что 301 – это всего лишь, код, который означает, что произошло перенаправление, а вот за склейку доменов отвечает HTTP сервер и его конфигурации, поэтому крайне неправильно говорить этот ваш редирект 301.

Мы немного отвлеклись, давайте перейдем к HTTP кодам состояния перенаправления, все HTTP коды перенаправления начинаются с тройки. Общей чертой HTTP кодов перенаправления является то, что все они сообщают браузеру о том, что для продолжения работы ему необходимо выполнить какие-либо дополнительные действия, обычно браузер выполняет эти действия не спрашивая пользователя.

Для удобства давайте сведем все HTTP коды состояния перенаправления в единую таблицу и дадим им краткое описание.

Давайте более подробно поговорим про каждый из кодов состояний HTTP сервера класса перенаправления.

HTTP код состояния 300: множественный выбор. HTTP код состояния 301: постоянно перенесен. HTTP код состояния 302: временно перемещен.

HTTP код состояния 300 или код множественного выбора говорит о том, что клиент может выбрать несколько доступных представлений ресурса, но не более пяти. Каждое представление ресурса имеет свое уникальное месторасположения на сервере. Формат, в котором клиент будет получать HTTP объект определяется медиа типом данных (читай про типы данных в HTTP по этой ссылке), указанным в поле заголовка Content-Type. Иногда выбор выполняется автоматически браузером без участия пользователя, но стандарт HTTP протокола не дает никаких критериев, по которым должен происходить автоматический выбор, а так же не имеет никаких требований. Ответы HTTP сервера с кодом состояния 300 по умолчанию являются кэшируемыми, если в заголовках не указано иного.

HTTP код состояния 301 или код состояния постоянного переноса. Код состояния 301 сообщает браузеру о том, что для ресурса, к которому он обратился, назначен новый URI, и все обращения к этому ресурсу следует выполнять по новому URI, указанному в ответе HTTP сервера. Ответы сервера с кодом 301 являются кэшируемыми. В тех случаях, когда клиент использовал HTTP запрос с методом отличным от GET или HEAD, браузер спрашивает у пользователя, что делать дальше: переходить по новому URI или не надо.

HTTP код состояния 302 или код временного перемещения ресурса. Код состояния 302 говорит о том, что на данный момент ресурс временно доступен по другому URI и сообщает новый URI ресурса. Кэшируемость ответов сервера с кодом 302 зависит только от значений полей заголовка Cache-Control или Expires. В тех случаях, когда клиент использовал запрос с методом отличным от GET или HEAD, браузер спрашивает у пользователя, что делать дальше: переходить по новому URI или не надо.

HTTP код состояния 303: смотреть другой ресурс. HTTP код состояния 304: ресурс не модифицирован. HTTP код состояния 305: использовать прокси сервер. HTTP код состояния 307: временное перенаправление

HTTP код состояния 303 или код состояния смотреть другой ресурс. Если клиент получает ответ с кодом 303, то это означает, что ответ на его запрос может быть найден по другому URI и его можно запросить при помощи метода GET. Чаще всего ответы с кодом состояния 303 используются, чтобы вывести информацию из формы. Ответы сервера с кодом 303 не кэшируются.

HTTP код состояния 304 или код состояния ресурс не модифицирован. Клиент получает ответ от HTTP сервера с кодом 304 в том случае, когда посылался запрос с условным методом GET, но никаких изменений в документе не произошло. При этом HTTP сообщение от сервера не должно содержать тела. Ответ сервера всегда содержит следующие поля заголовков:

Ответы сервера с кодом 304 всегда завершаются пустой строкой после полей заголовка.

HTTP код состояния 305. Код состояния 305 говорит браузеру о том, что ему нужно обратиться к ресурсу, используя прокси-сервер. Прокси-сервер в сообщениях с кодом состояния 305 указывается в поле Location. При этом HTTP сервер ожидает, что клиент повторит запрос, но уже через прокси сервер и даже при необходимости пройдет аутентификацию на прокси сервере.

HTTP код состояния 306 использовался в старых версиях протокола HTTP, но теперь является просто зарезервированным.

HTTP код состояния 307 аналогичен коду состояния 302.

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

HTTP Status Code 302: What Is the 302 «Moved Temporarily» Redirect?

Status Code 302: «Moved Temporarily»

HTTP Status Code 302: «Moved Temporarily»

Usually, 302 redirects are used incorrectly. There are not many situations where you would want to use them as a webmaster or digital marketer.

A 302 redirect seems similar to a 301 redirect. They do the same thing for the user: move them to a new location. The difference, is that one is a permanent redirect, and the other is a temporary redirect.

A permanent (301) redirect says «Hey Google, this page has been permanently moved to this new location. Any of the rankings and link equity that it used to have, please pass those on to the new URL».

A temporary (302) redirect says «Hey Google, this page has been temporarily moved to this new location. Do not pass any of the rankings and link equity to the new location».

Let’s say you were running a Superbowl television ad, and your call to action was «Visit us at Website.com». And just for that day, you wanted to temporarily redirect all the traffic that came to your homepage, to Website.com/superbowl-ad. That might be one instance where you’d be okay with a temporary redirect.

Other situations where you might use this might be temporary situations when you’re collecting data. For example, if you are manually doing an A/B test and bucketing users on your own, you might want to implement a 302 redirect.

Usually, you want to stick with 301 redirects instead.

The HTTP Protocol

Let’s talk about how the HTTP protocol works.

At its very foundation, the Internet is made up of two core things: clients and servers.

Any time you click on your browser, you are accessing the Internet through a web client. It may be Chrome, Firefox, Safari or Internet Explorer.

When you visit a website, you are making a request to a web server.

Facebook.com, ClickMinded.com, MarthaStewart.com/1525880/marthas-chocolate-chip-cookies, all of these sites have their own home address. It’s called an IP address.

Your home address might be 123 Main Street, New York, NY 10001, and Facebook’s address happens to be 66.220.144.0.

Whenever you visit a page on the web, you are requesting a whole bunch of documents from that website’s server. Maybe those documents are HTML, CSS, images, a PDF—whatever it is, the basic relationship stays the same: you (the client), make a request, and the website (the server) responds to that request.

The language you are using to make these requests is called the HTTP protocol. These protocols are really just standards that everyone on the web has agreed to. Just like English, Spanish and Chinese are all languages that have an understood protocol, HTTP is just a bunch of standards and an understood protocol.

There are a number of different web protocols out there – and you might be familiar with some of them:

HTTP Status Codes

Now that we understand what the HTTP protocol is, let’s talk about HTTP status codes. Status codes let us know whether the HTTP request was a success, a failure, or something in between.

Let’s take a look at the five core status codes:

Let’s briefly go over each status code block and what they mean.

1xx Status Codes

These are informational requests. The server hasn’t fully completed the request yet and it’s still processing the information. You will not see these codes often. They include:

2xx Status Codes

These are successful requests, which means everything is okay. They include:

3xx Status Codes

These are redirects. These are shown when you request an address, but you are sent somewhere else. These can be good or bad. They include:

4xx Status Codes

These are client errors. That means something went wrong with the request (client/user) and not the response (website/server). They include:

5xx Status Codes

These are server errors. That means something went wrong with the response (website/server) and not the request (client/user). They include:

In Conclusion

Looking for more on a particular status code? We have a series of short guides on every HTTP response, so you can optimize your digital marketing strategy. Grab them here:

HTTP 302

Contents

What is the HTTP status code 302?

The HTTP status code 302 is an HTTP response code that indicates a resource has been temporarily moved to a different location than the one being accessed. The HTTP status code 302 is a useful way to redirect users from old URLs to new ones, which also works well with search engines. The 302 response code preserves the original URL, with the intention of restoring it at some point in the future.

What are 302 redirects used for?

302 responses are used to redirect an access request from one URL to another. They are most commonly used when web addresses or resource storage locations change. It is important to note that 302 is specifically for temporary redirections. It is intended to enable page requests to be routed to the correct location, but without affecting the URL search engines use when indexing the page.

Examples for 302 redirect implementations

You can also use PHP to implement a 302 redirect:

A limitation of this implementation is that it can only be used with pages containing HTML. This means that it cannot be used with images or other multimedia file requests.

Content Management Systems may offer plugins or native features that help implement redirects. For example, WordPress supports a wp_redirect() function. This allows programmers to implement a 302 redirect within the code of a website. For those without access to the underlying code, there are also plugins that can be used to implement 302 redirects. An example of this is the Quick Page/Post Redirect Plugin.

Redirects may be chained, though performance can degrade with each subsequent redirect, so they should be limited to as few as possible. You should avoid redirect loops, which can result in pages becoming inaccessible to search engines and visitors.

301 redirect vs 302

The difference between using a 301 or 302 response is whether or not the page being requested has moved permanently or temporarily. The HTTP 302 response is intended for temporary redirections. If content is moved permanently, a 301 response should be used instead.

When to use 301 redirects

HTTP 301 redirects are intended to be used when a page or resource has been moved permanently. Using a 301 status code enables search engine crawlers and client browser caches to update indexed URLs. Once a 301 redirect has been accessed, the URL of the original request will be replaced with the redirected URL. This enables sites to preserve search result rankings for the same page when it is moved to a different location.

When to use 302 redirects

Since HTTP 302 redirects are intended to be used for temporary redirects, possible applications include promotional sales pages or A/B tests. Another example would be technical errors or site maintenance.

In these cases, a temporary redirect could be put in place to graciously handle access requests while preventing users from accessing the page. Search engines and browser caches will not forget the original URL and will attempt to access it again on subsequent visits.

Importance of HTTP 302 status codes for SEO

Using HTTP 302 status codes is highly recommended from an SEO perspective. If the location of a resource has changed and no redirect status codes are issued, they will instead return another status code, typically 404. This is the ‘page not found’ status code, and it indicates a resource was not found at the provided URL.

Search engines such as Google continually recrawl and re-index websites. How often any particular site is re-indexed will depend on many factors, but pages and locations that return 404 status codes will be removed from search results. This means that pages that appear high in search results risk being removed, potentially resulting in major traffic losses.

The key difference between using a 301 or 302 redirect is how search engines and browsers deal with the original URL. When a 301 permanent redirect is used, browser caches and search engine crawl bots update the URL of the resource and do not attempt to access the original URL again. When a 302 temporary redirect is used, browser caches and search engine crawl bots will continue to try to access the original URL in subsequent visits.

In summary: HTTP 302 FAQs

What does the HTTP 302 status code mean?

The HTTP 302 status stands for “Found” and means that a resource has been temporarily relocated to another URL.

How do you implement 302 redirects?

What is the difference between 301 and 302 redirects?

301 redirects mean that a file has been moved permanently, while 302 redirects are used for temporary redirects.

Why is the 302 status code important for SEO?

The 302 status code is relevant for SEO because if you change a file’s location without a redirect, your page might show a 404 error. Resources that return that kind of error will be removed from search results.

After a POST, should I do a 302 or a 303 redirect?

A common scenario for a web app is to redirect after a POST that modifies the database. Like redirecting to the newly created database object after the user creates it.

It seems like most web apps use 302 redirects, but 303 seems to be the correct thing to do according to the specification if you want the url specified in the redirect to be fetched with GET. Technically, with a 302, the browser is supposed to fetch the specified url with the same method that the original url was fetched with, which would be POST. Most browsers don’t do that though.

So should I be using 302 or 303?

5 Answers 5

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

The correct one is 303.

I use it and haven’t found any compatibility problems with UAs newer than Netscape 4 (1998, released 17 years ago).

If you use 302, you’re risking that UA will re-send POST to the new URL instead of switching to GET.

Still, if you’re worried about HTTP/1.0 clients (which don’t support vhosts and probably won’t be able to access your page anyway) then you should include HTML with link to the new page in body of the 303 response (web servers like Apache do that already).

Depends.
303 and 307 responses were added in HTTP1.1.
So client agents that are strictly compliant to HTTP1.1 RFC should be fine with a 303 response.
But there can be agents that are not fully conformant or are HTTP1.0 compliant and will not be able to handle the 303.
So to be sure that the response of your application can be handled gracefully by the majority of client implementations I think 302 is the safest option.
Excerpt from RFC-2616:

Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.

In most server-side languages the default redirection mechanism uses 302:

So I’d prefer this, rather than setting status and headers manually.

In theory, you (and all the world) should be using 303 as you have noted. But also, most browsers react to a 302 like they should react to a 303. So, overall, it seems that it won’t matter if you send 302 or 303. In the link you provided for the 303 specification, theres an interesting note:

Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.

It’s important to note the pre-HTTP/1.1 user agents, so maybe this was important a while ago, but I don’t believe it is the case now.

So, all in all, it’s up to you (I could bet whatever you want that browsers won’t change their behavior against 302 statuses never, for fear of breaking the internet for their users).

What happens when a browser encounters a 302 header status code?

Does the browser make a new request to the location given in the header?

I ask because I was playing around with Fiddler and noticed when I make a request to a page that returns a 302 HTTP code, there are two entries in the network log. The first is to the initial URL, and the second is to the new location given in the response header of the first request.

I’m just curious if web browsers work the same way, but just hide the first response from the user.

1 Answer 1

Yes, the browser works in very much similar fashion. You can try requesting a url in Chrome, possibly the one you tried in Fiddler. The Network Log of chrome would show you two requests.

The RFC description of HTTP status code can be read over here,

Quoting from there only, regarding the 302 status code:

RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

When a server responds with a 302 status code, it send back the newer url (to which the current requested old url is to be redirected) to the requesting user-agent (likely a browser). Now, as per the RFC document, the user agent must not request the newer url for 302 status code. Yet most of them do make a second request.

Коды состояния – руководство

Коды состояния HTTP и как их интерпретировать

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

Каждый раз, когда пользователь нажимает на ссылку или переходит на URL сайта, браузер посылает запрос к веб-серверу. Сервер, в свою очередь, обрабатывает запрос и возвращает ответ, содержащий информацию о том, успешно ли был обработан запрос. Результат обработки запроса передается в первой строке ответа и называется кодом состояния. Код состояния можно представить как небольшую заметку, которую веб-сервер прикрепляет к запрашиваемой странице. Он является не частью веб-страницы, а неким сообщением от сервера, дающим вам знать, что произошло при попытке обработать запрос. Такие сообщения возвращаются каждый раз, когда браузер посетителя сайта взаимодействует с сервером, даже если вы не видите их.

Именно поэтому коды состояния HTTP являются бесценным инструментом для диагностики и исправления ошибок конфигурации веб-сайта.

Код состояния HTTP (англ. HTTP status code) — это целое трехзначное число в первой части ответа сервера при запросах по протоколу HTTP.

Классы кодов состояния:

Все коды состояния разделяются на классы. Класс состояния указывается в первой цифре, две следующие – уточняющие.

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

Список кодов состояния:

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

200 Код состояния

300 Коды состояния

400 Коды состояния

500 Коды состояния

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

В случае, если обнаруженный код отсутствует в списке, вы можете воспользоваться следующими ресурсами:

Используйте этот материал как ваш путеводитель по кодам состояния HTTP. Их понимание действительно важно для развития вашего сайта и может спасти вас от многих неприятностей – помните их и применяйте информацию в будущем!

301, 404, 503 и другие цифры — как с ними работать?

Каждый раз, когда мы кликаем на какую-то ссылку или на наш сайт заходят поисковые роботы, происходит один из диалогов примерно такого содержания:

— Привет, сервер! Я поисковый робот. Могу я просканировать эту страницу?

— Привет! Конечно, заходи.

— А если вот эту страницу?

— А вот здесь пока ведутся ремонтные работы, приходи позже.

Язык ответов HTTP понимают и браузеры, и поисковые роботы, и SEO-специалисты, которым он нужен при работе с сайтом.

Если вы до сих пор путаете 301 с 302, и не знаете, зачем нужен 410 ответ — вам просто необходимо разобраться в кодах ответов HTTP, которые встречаются чаще всего. О них я и расскажу в этой статье. А еще мы узнаем, какую роль они отыграют в SEO и как не допустить ошибок в их использовании.

Какие ответы серверов существуют?

Начнем с того, что все коды ответов (состояния) серверов делятся на 5 классов, каждый из которых несет определенный смысл:

Не все ответы сервера можно увидеть прямо на экране, большинство так и остаются внутренними кодами для браузеров и поисковых роботов. Чтобы быстро узнать статус любой страницы, откройте инструменты разработчика в браузере Chrome (нажмите F12). Перейдите на вкладку Network, обновите страницу и получите список статусов каждого элемента, включая саму страницу:

Именно в этих трех цифрах в колонке Status зашифрованы данные о состоянии страницы: можно ли ее сканировать, находится ли она по этому адресу, загружается ли все ее содержимое и т. д.

Какие же коды ответов сервера встречаются чаще всего? И что они значат для оптимизации сайта? Давайте внимательно рассмотрим самые полезные для SEO ответы и способы их обработки.

Ответы серверов, которые встречаются чаще всего

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

301 Moved Permanently

Говорит о том, что URL был навсегда перенесен на новое место. Браузеры самостоятельно переходят по 301 переадресации — никакого действия от пользователя не требуется.

301 код ответа обычно используют при переводе сайта с HTTP на HTTPS, склейке зеркал (страниц с www и без www), настройке слеша в конце URL, а также при переносе части сайта или всех страниц на новый домен. Этот редирект идеально подходит, если вы хотите передать ссылочный вес старой страницы на новую и сохранить результаты SEO-продвижения.

Совет: Старайтесь не перенаправлять пользователей с удаленного URL на главную страницу сайта. Например, в вашем интернет-магазине есть карточка с неактуальным товаром, но с неплохой ссылочной массой. Вы хотите сохранить этот вес и ставите 301 редирект на главную. Здесь и кроется ошибка! Такой редирект воспринимается Google как 404 Soft, а это означает, что поисковик не будет передавать сигналы со старого URL на новый. В такой ситуации всегда перенаправляйте страницу на максимально похожую (или 404, если аналогичная страница отсутствует).

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

302 Found / Moved Temporarily

В отличие от постоянного 301 редиректа, этот — временный. Он говорит о том, что страница найдена, но пока размещена по другому адресу.

Обычно его путали с 301, а после того, как Google объявил, что все 3хx редиректы передают ссылочный вес, — ситуация усугубилась. По факту, его нужно ставить, если вы точно уверены, что будете использовать старый URL снова. Как раз об этом вы и сообщаете поисковику с помощью 302 сигнала, а он в ответ оставляет весь ссылочный вес за старой страницей.

Если вы будете использовать 302 редирект на постоянной основе, Google в конечном итоге воспримет его как 301 со всеми вытекающими последствиями. Также проверьте, нет ли на вашем сайте 302 редиректов, которые на самом деле должны быть 301 — такая ошибка встречается очень часто.

304 Not Modified

Сервер отдает 304 Not Modified ответ, когда страница остается неизменной со времени последнего посещения.

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

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

Лучший ответ сервера для оптимизатора ― 200 ОК. Он означает, что запрос успешно обработан. Но 304 несет ту же нагрузку. Как правило, на новые страницы и первое посещение должен выдаваться ответ 200, на все последующие, если не произошло изменений — 304.

403 Forbidden

Этот код ответа говорит о том, что пользователю запрещен доступ к странице.

403 ошибка может появиться, если пользователь вошел на сайт, но у него нет разрешения для доступа к закрытой внутренней сети. Например, если я попытаюсь зайти в кабинет админа SE Ranking по прямому URL, используя пароль и логин личного аккаунта, на экране будет 403 ошибка «Нет доступа». Также 403 ошибка возникает, если индексный файл для главной указан неправильно. Он обязательно должен иметь название index и расширение: *.shtml, *.html, *.htm, *.phtml или *.php.

Кроме того, когда вы переносите сайт на HTTPS, то 403 ответ появится, когда DNS-кэш ещё не успел обновиться, а вы уже что-то от него хотите. Лучше подождите, или, если это вопрос жизни и смерти, обновите кэш принудительно.

Совет: страницы с 403 кодом ответа в конечном итоге будут удалены из индекса, поэтому Google рекомендует использовать 404 ответ вместо 403.

404 Not Found

Самая «любимая» ошибка в SEO. Говорит о том, что сервер ничего не нашел по указанному адресу, хотя соединение между сервером и клиентом прошло успешно.

Не стоит переживать, если вы увидите много 404 страниц в своей Google Search Console. Поисковик просто сообщает вам, какие страницы удалены, а вам уже решать, нужно ли их проверять. Но что стоит точно сделать — убрать все ссылки на удаленные страницы, чтобы не путать посетителей при навигации по вашему сайту.

Обычно мы видим этот код ошибки, когда вводим неправильный URL в браузер и, как следствие, пытаемся получить доступ к несуществующей странице. Или, например, владелец сайта удалил страницу без редиректа URL по новому адресу. Как результат — 404 ошибка. Чтобы решить проблему, посетителю нужно перепроверить написание URL или попробовать найти информацию на сайте самостоятельно через поиск, а владельцу ресурса ― исправить «битые» ссылки на рабочие.

404 страница не индексируется и не передает вес. Поэтому некоторые оптимизаторы грешат «мягкой 404», выдавая стандартную страницу с ответом 200 вместо 404. Но это считается плохой практикой, потому что 200 код говорит Google, что по этому URL есть реальная страница. В конечном счете, страница оказывается в индексе, и поисковик продолжает свои попытки сканировать несуществующие URL-адреса вместо сканирования ваших реальных страниц.

Как настроить 404 страницу для своего сайта

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

Если ваша CMS (система управления контентом) не создала 404 страницу, вы можете создать ее самостоятельно.

С помощью htaccess

Самый простой способ настроить страницу с 404 ошибкой — добавить сообщение об ошибке, например ErrorDocument 404 “

В результате у вас должно получиться что-то вроде этого:

Через PHP

Вы можете использовать функцию заголовка и менять контент 404 страницы в зависимости от разных сценариев (например, юзер сделал ошибку в URL самостоятельно или уже перешел по «битой» ссылке с какого-то ресурса).

Детальнее — в этой инструкции.

Через WordPress

У вас есть несколько вариантов:

Подробности можно узнать здесь.

410 Gone

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

Более того, инструмент проверки URL в Google Search Console обозначает 410 ответы как 404, что приводит к еще большему количеству 404 ошибок, обнаруженных в консоли.

«Удалено»

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

Поскольку Google все-таки относится к 404 и 410 ошибкам по-разному, нужно использовать 410 код только тогда, когда вы точно знаете, что страница удалена и больше не вернется. Такой ответ по умолчанию кэшируется, поисковый робот больше не заходит на страницу, а она в свою очередь удаляется из индекса.

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

503 Service Unavailable

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

«Сервис недоступен»

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

Могут быть ещё такие причины:

Совет: в идеале в сообщении с 503 ошибкой обязательно нужно указать, что пользователю нужно вернуться на сайт через Х времени. К сожалению, так очень редко делают — обычно просят попытать удачу позже.

И последнее, но не менее важное: код состояния 503 не позволяет поисковым системам индексировать сайт. Кроме того, он сообщает, что сайт плохо обслуживается, потому что пользователи не могут попасть, куда хотели. Поэтому важно, чтобы неполадки были устранены как можно быстрее — иначе это скажется на позициях сайта.

Как настроить 503 страницу для своего сайта через PHP

Вот как выглядит код состояния 503 в PHP:

Больше подробностей можно почитать в этой инструкции.

Как проверить коды состояния всех страниц на сайте

Чтобы быть в курсе всего, что происходит на вашем сайте, нужно мониторить коды состояния всех ваших страниц. Конечно, для этого можно использовать расширение Live HTTP Headers для Chrome или отчет «Покрытие» в Google Search Console, но лучше, если вы проанализируете ответы до того, как до них доберутся поисковые роботы.

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

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

Все статусы страниц вы увидите в основном отчете, в котором проанализированы технические параметры, страницы, мета-теги, ссылки и контент.

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

Если же вас интересуют только коды состояния всех страниц, просто перейдите на вкладку «Сканированные страницы». Все данные можно экспортировать в формате XLS для подробного изучения:

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

Чтобы сдать этот экзамен на отлично, мы подготовили для вас шпаргалку по правилам HTTP-знаков с лучшими SEO-советами. Теперь какой бы знак не встретился у вас на пути, вы будете знать, что делать.

I have a page that shows status codes that I cannot make sense of.

Why would this page show a 302 for another page if the actual page can be found?

1 Answer 1

HTTP Status Code 302 is meaning you redirected from a site to an other one.

Basicly if I understand you case it means you ping Url A which is not living anymore, but has a proxy to point to its new location. So you get 302 after hitting the url and 200 after you are moved to the current url.

Not the answer you’re looking for? Browse other questions tagged http-status-code-302 or ask your own question.

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

302 found response

I have implemented ajax request to populate my drop down fields. It is working Fine but when I stay idle for some time and select some value in drop down the ajax request gets 302 found response. Is it due to session out. Please let me know the solution, can we do some setting that it will never get response as 302 found.

2 Answers 2

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

The 302 status code indicates that the resource you are requesting has redirected to another resource. If this is behind some authentication, or requiring a session to be active then yes, it would follow that the session timing out is responsible for the ajax resource being called to redirect to possibly a login screen maybe.

I would seriously recommend using something like Charles or Fiddler to track the requests being made.

Redirections in HTTP

URL redirection, also known as URL forwarding, is a technique to give more than one URL address to a page, a form, or a whole Web site/application. HTTP has a special kind of response, called a HTTP redirect, for this operation.

Redirects accomplish numerous goals:

Principle

When browsers receive a redirect, they immediately load the new URL provided in the Location header. Besides the small performance hit of an additional round-trip, users rarely notice the redirection.

There are several types of redirects, sorted into three categories:

Permanent redirections

These redirections are meant to last forever. They imply that the original URL should no longer be used, and replaced with the new one. Search engine robots, RSS readers, and other crawlers will update the original URL for the resource.

[1] The specification did not intend to allow method changes, but there are existing user agents that do change their method. 308 was created to remove the ambiguity of the behavior when using non- GET methods.

Temporary redirections

Sometimes the requested resource can’t be accessed from its canonical location, but it can be accessed from another place. In this case, a temporary redirect can be used.

Search engine robots and other crawlers don’t memorize the new, temporary URL. Temporary redirections are also used when creating, updating, or deleting resources, to show temporary progress pages.

[2] The specification did not intend to allow method changes, but there are existing user agents that do change their method. 307 was created to remove the ambiguity of the behavior when using non- GET methods.

Special redirections

304 (Not Modified) redirects a page to the locally cached copy (that was stale), and 300 (Multiple Choice) is a manual redirection: the body, presented by the browser as a Web page, lists the possible redirections and the user clicks on one to select it.

Alternative way of specifying redirections

HTTP redirects aren’t the only way to define redirections. There are two others:

HTML redirections

HTTP redirects are the best way to create redirections, but sometimes you don’t have control over the server. In that case, try a element with its http-equiv attribute set to Refresh in the of the page. When displaying the page, the browser will go to the indicated URL.

The content attribute should start with a number indicating how many seconds the browser should wait before redirecting to the given URL. Always set it to 0 for accessibility compliance.

Obviously, this method only works with HTML, and cannot be used for images or other types of content.

JavaScript redirections

Redirections in JavaScript are performed by setting a URL string to the window.location property, loading the new page:

Like HTML redirections, this can’t work on all resources, and obviously, this will only work on clients that execute JavaScript. On the other hand, there are more possibilities: for example, you can trigger the redirect only if some conditions are met.

Order of precedence

With three ways to trigger redirections, several ways can be used at the same time. But which is applied first?

When possible, use HTTP redirects and don’t add element redirects. If someone changes the HTTP redirects but forgets to change the HTML redirects, the redirects will no longer be identical, which could cause an infinite loop or other nightmares.

Use cases

There are numerous use cases for redirects, but as performance is impacted with every redirect, their use should be kept to a minimum.

Domain aliasing

Ideally, there is one location, and therefore one URL, for each resource. But there are reasons for alternative names for a resource:

Expanding the reach of your site

Moving to a new domain

For example, your company was renamed, but you want existing links or bookmarks to still find you under the new name.

Requests to the http:// version of your site will redirect to the https:// version of your site.

Keeping links alive

When you restructure Web sites, URLs change. Even if you update your site’s links to match the new URLs, you have no control over the URLs used by external resources.

You don’t want to break these links, as they bring valuable users and help your SEO, so you set up redirects from the old URLs to the new ones.

Note: This technique does work for internal links, but try to avoid having internal redirects. A redirect has a significant performance cost (as an extra HTTP request occurs). If you can avoid it by correcting internal links, you should fix those links instead.

Temporary responses to unsafe requests

Unsafe requests modify the state of the server and the user shouldn’t resend them unintentionally.

In this case, the server can send back a 303 (See Other) response for a URL that will contain the right information. If the reload button is pressed, only that page is redisplayed, without replaying the unsafe requests.

Temporary responses to long requests

Some requests may need more time on the server, like DELETE requests that are scheduled for later processing. In this case, the response is a 303 (See Other) redirect that links to a page indicating that the action has been scheduled, and eventually informs about its progress, or allows to cancel it.

Configuring redirects in common servers

Apache

The mod_alias module has Redirect and RedirectMatch directives that set up 302 redirects by default:

RedirectMatch does the same, but takes a regular expression to define a collection of affected URLs:

All documents in the images/ directory will redirect to a different domain.

If you don’t want a temporary redirect, an extra parameter (either the HTTP status code to use or the permanent keyword) can be used to set up a different redirect:

The mod_rewrite module can also create redirects. It is more flexible, but a bit more complex.

Nginx

In Nginx, you create a specific server block for the content you want to redirect:

To apply a redirect to a directory or only certain pages, use the rewrite directive:

In IIS, you use the element to configure redirections.

Redirection loops

Redirection loops happen when additional redirections follow the one that has already been followed. In other words, there is a loop that will never be finished and no page will ever be found.

Sometimes, the server won’t detect it: a redirection loop can spread over several servers which each don’t have the full picture. In this case, browsers will detect it and display an error message. Firefox displays:

Firefox has detected that the server is redirecting the request for this address in a way that will never terminate.

…while Chrome displays:

This Webpage has a redirect loop

In both cases, the user can’t do much (unless corruption is happening on their side, like a mismatch of cache or cookies).

It is important to avoid redirection loops, as they completely break the user experience.

How to fix Server Status Code: 302 Found by SQL Inject Me Firefox Addon

I scanned my login script using SQL Inject Me Firefox addon

According to the Test Results, my script was vulnerable to SQL Injection. Result by example

$_SESSION[‘login_mes’] = «Invalid email address or password, please try again.»; header(«Location:login.php»); exit(); >

The problems came when login failed. If I remove the

No failures detect by SQL Inject Me and how to fix this part?

4 Answers 4

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

302 is the server’s way of saying «I want you to go to [somewhere else]» (in this case login.php). It is not an error but a perfectly normal response. Especially in your case it makes much more sense (if you ask me) to send the user to a login page after a SQL injection attempt than to let him in.

Four years later but I was just looking into this question and thought that I would share for the next person.

After some analysis, we concluded that the 302 is in itself not a concern. The concern is what page preceded the 302 which might have been sent but was swept away by the 302 before it could be displayed. If the previous page received by the browser (and perhaps recorded by Fiddler) contained database errors (or other information that a hacker might find useful) than that is bad. If the 302 is the initial response and it has an empty body, just a header, then I think that you are OK.

You have to display the error page (the purpose of the 302) so I don’t see how that could be considered «too much information».

HTTP Status Codes

An interim response and client should continue with request

Indicates to client / browser the server is switching protocols

Server is processing the request

Resume aborted PUT or GET requests

The URI is too long and exceeds the maximum 2083 characters

Server successfully processed request

Request was successful and server created new resource

Request accepted but not processed yet

Request processed successfully but information returned may be from another source

Request completed but no content was returned

Request completed but no content was returned; requires requestor reset document view

Server delivered a partial GET request

Successful response for WebDAV

Results previously returned and not inlcuded again

Content and/or property mismatch between client and server

Server has fulfilled the request and response is an instance manipulated result

Server has multiple actions available based on the request; user can select from list

Requested page has been permanently moved to a different URL

Moved Temporarily / Found

Requested page has been temporarily moved to a different URL; requestor should continue to use original URL

The requested page can be located at a different URL; user is not automatically forwarded

Page has not been modified sonce last request

Requestor must use a proxy to access the requested page

Requested page has been temporarily moved to a different URL; requestor should continue to use original URL

Used in resumable requests proposal to resume aborted POST and PUT requests

Request cannot be fulfilled due to incorrect syntax

Authentication is required or has not been provided

Not currently used. Intended for use in digital cash transactions

Client does not have suffcient permissions to access the requested resource

Requested page cannot be found at current location but could be available in the future

Method Not Allowed

Request was made using a method not supported by page

Server can provide only content that is unacceptable to the client

Proxy Authentication Required

Client must authenticate with a proxy to access resource

Server timed out waiting for request from client

Request could not be processed due to a conflict

The requested page is no longer available and will not be available again

Server has denied request due to unspecified length of content

Resource does not meet conditions of client’s request

Request Entity Too Large

Request is too large to fulfill

Request URI Too Long

Requested URL is too long for the server to process

Unsupported Media Type

Server does not media type requested

Requested Range Not Satisfiable

Client requested portion of file but server cannot satisfy the request

Server cannot meet requirements of Expect request header field

An IETF April Fools’ joke

Enhance Your Calm

Client rate limiting by Twitter

Unable to process request due to semantic errors

Requested resource is locked

Request failed due to

Client should switch to a different protocol

Server requires request to be conditional to prevent conflicts

Too Many Requests

User has sent too many requests in a specified time period

Request Header Fields Too Large

Request cannot be processed due to individual field or collective fields are too large

Indicates Nginx server has not returned requested information and has closed connection

Request should be performed after the specified action

Blocked By Windows Parental Controls

Page blocked by Windows Parental Controls

Either more efficient server available or server can’t access user’s mailbox

Client Closed Request

Indicates client has closed connection prior to server completing request

Internal Server Error

Server encountered an unexpected condition that prevented request fulfillment.

Request is unrecognizable or server lacks ability to fulfill it

Server received an invalid response from an upstream server and could not fulfill request

Server is currently unavailable

Server did not receive a timely response from upstream server

HTTP Version Not Supported

Server does not support the HTTP protocol used in request

Variant Also Negotiates

Content negotiation results in circular reference

Server detected an infinite loop while processing request

Bandwidth Limit Exceeded

Apache extension not defined in RFC’s to communicate bandwidth allocation exceeded

Further extensions to the request are required to fulfill it

Network Authentication Required

Client is required to authenticate to gain network access

Network Read Timeout Error

Client behind proxy experiences network read timeout error

Network Connect Timeout Error

Client behind proxy experiences network connect timeout error

while hitting an API Request throws 302 status code how to solve this

I’m hitting an API using http dart library while doing this I’m getting 302 status code. I know that 302 status code is for redirects, can you please say how can i enable redirects in http post method. I have used the following code:

2 Answers 2

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

302 is a status code returned by the server to indicate that the client should retry the request using a different URL. It’s a way to redirect the client to a different endpoint.

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

A well-behaved API should probably not issue 30X in response to a POST, but it is. The way to get around this is to make a new http request with the redirected URL. (You might want to put it in a while loop to keep following the redirects until you get to 200, or some error, or reach a timeout/limit.)

What is correct HTTP status code when redirecting to a login page?

When a user is not logged in and tries to access a page that requires login, what is the correct HTTP status code for a redirect to the login page?

I am asking because none of the 3xx response codes set out by the W3C seem to fit the requirements:

10.3.1 300 Multiple Choices

The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.

Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of

the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.

If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise.

10.3.2 301 Moved Permanently

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

10.3.3 302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

10.3.4 303 See Other

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

10.3.5 304 Not Modified

If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.

The response MUST include the following header fields:

clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.

section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.

If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.

If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.

10.3.6 305 Use Proxy

The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers.

10.3.7 306 (Unused)

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

10.3.8 307 Temporary Redirect

The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

I’m using 302 for now, until I find the correct answer.

Update & conclusion:

HTTP 302 is better since its known to have best compatibility with clients/browsers.

HTTP status code 302

Im working on my Rails Backend in Ruby and i want to post Data to this server. But if i do a Post-request with PAW i get redirected. Im a newbie to Http Requests. Could someone explain me the functionality and how to use http post requests?

i want to post information on my server’s datanase (sqlite3).

Here’s a screenshot which should explain everything:

how does this work? please explain 🙂 thanks. greetings John

and here’s the code:

It’s telling 200 ok but nothing happens in the DB.

from Paw-Request (so i can use post. btw. how do i use post in browser request?

Started POST «/owners?name=hans&password=[FILTERED]&password_confirmation=[FILTERED]» for 192.168.2.144 at 2015-10-01 12:12:45 +0200 Cannot render console from 192.168.2.144! Allowed networks: 127.0.0.1, ::1, 127.0.0.0/127.255.255.255 Processing by OwnersController#create as HTML Parameters: <"name"=>«hans», «password»=>»[FILTERED]», «password_confirmation»=>»[FILTERED]»> Can’t verify CSRF token authenticity Redirected to http://192.168.2.144:3000/ Filter chain halted as :authenticate_user rendered or redirected Completed 302 Found in 1ms (ActiveRecord: 0.0ms)

It seems that the CRSF authentication failed..

at first: to Rich Peck! This helped me so much. Thank you!! I really appreciate your effort.

Im near to the solution.. My problem is: i cant put the correct params in the url. The token-auth is disabled for testing. so it wont matter.

the params should be like: Parameters: <"utf8"=>«✓», «authenticity_token»=>»q9JvFhoSUgfydFTvh18JHbIIdKNDjnOS9m/trVBu9EHPP04xGsO69zPh1BFZBI1Ev1YcnOTiPmaAiPWOSkm5Xg==», «owner»=><"name"=>«Hubert», «password»=>»[FILTERED]», «password_confirmation»=>»[FILTERED]»>, «commit»=>»Create Owner»>

and not as in my request: Parameters: <"name"=>«Hubert», «password»=>»[FILTERED]», «password_confirmation»=>»[FILTERED]», «owner»=><>>

HTTP redirect: 301 (permanent) vs. 302 (temporary)

Is the client supposed to behave differently? How?

7 Answers 7

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

Status 301 means that the resource (page) is moved permanently to a new location. The client/browser should not attempt to request the original location but use the new location from now on.

Status 302 means that the resource is temporarily located somewhere else, and the client/browser should continue requesting the original url.

When a search engine spider finds 301 status code in the response header of a webpage, it understands that this webpage no longer exists, it searches for location header in response pick the new URL and replace the indexed URL with the new one and also transfer pagerank.

So search engine refreshes all indexed URL that no longer exist (301 found) with the new URL, this will retain your old webpage traffic, pagerank and divert it to the new one (you will not lose you traffic of old webpage).

Browser: if a browser finds 301 status code then it caches the mapping of the old URL with the new URL, the client/browser will not attempt to request the original location but use the new location from now on unless the cache is cleared.

When a search engine spider finds 302 status for a webpage, it will only redirect temporarily to the new location and crawl both of the pages. The old webpage URL still exists in the search engine database and it always attempts to request the old location and crawl it. The client/browser will still attempt to request the original location.

Mostly 301 vs 302 is important for indexing in search engines, as their crawlers take this into account and transfer PageRank when using 301.

See Peter Lee’s answer for more details.

301 is that the requested resource has been assigned a new permanent URI and any future references to this resource should be done using one of the returned URIs.

302 is that the requested resource resides temporarily under a different URI.

Since the redirection may be altered on occasion, the client should continue to use the Request-URI for future requests.

This response is only cachable if indicated by a Cache-Control or Expires header field.

301 redirects are cached indefinitely (at least by some browsers).

This means, if you set up a 301, visit that page, you not only get redirected, but that redirection gets cached.

When you visit that page again, your Browser* doesn’t even bother to request that URL, it just goes to the cached redirection target.

The only way to undo a 301 for a visitor with that redirection in Cache, is re-redirecting back to the original URL**. In that case, the Browser will notice the loop, and finally really request the entered URL.

Obviously, that’s not an option if you decided to 301 to facebook or any other resource you’re not fully under control.

Unfortunately, many Hosting Providers offer a feature in their Admin Interface simply called «Redirection», which does a 301 redirect. If you’re using this to temporarily redirect your domain to facebook as a coming soon page, you’re basically screwed.

*at least Chrome and Firefox, according to How long do browsers cache HTTP 301s?. Just tried it with Chrome 45. Edit: Safari 7.0.6 on Mac also caches, a browser restart didn’t help (Link says that on Safari 5 on Windows it does help.)

302 found response

I have implemented ajax request to populate my drop down fields. It is working Fine but when I stay idle for some time and select some value in drop down the ajax request gets 302 found response. Is it due to session out. Please let me know the solution, can we do some setting that it will never get response as 302 found.

2 Answers 2

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

The 302 status code indicates that the resource you are requesting has redirected to another resource. If this is behind some authentication, or requiring a session to be active then yes, it would follow that the session timing out is responsible for the ajax resource being called to redirect to possibly a login screen maybe.

I would seriously recommend using something like Charles or Fiddler to track the requests being made.

HTTP Messages

HTTP messages are how data is exchanged between a server and a client. There are two types of messages: requests sent by the client to trigger an action on the server, and responses, the answer from the server.

HTTP messages are composed of textual information encoded in ASCII, and span over multiple lines. In HTTP/1.1, and earlier versions of the protocol, these messages were openly sent across the connection. In HTTP/2, the once human-readable message is now divided up into HTTP frames, providing optimization and performance improvements.

Web developers, or webmasters, rarely craft these textual HTTP messages themselves: software, a Web browser, proxy, or Web server, perform this action. They provide HTTP messages through config files (for proxies or servers), APIs (for browsers), or other interfaces.

The HTTP/2 binary framing mechanism has been designed to not require any alteration of the APIs or config files applied: it is broadly transparent to the user.

HTTP requests, and responses, share similar structure and are composed of:

The start-line and HTTP headers of the HTTP message are collectively known as the head of the requests, whereas its payload is known as the body.

HTTP Requests

Start line

HTTP requests are messages sent by the client to initiate an action on the server. Their start-line contain three elements:

Headers

HTTP headers from a request follow the same basic structure of an HTTP header: a case-insensitive string followed by a colon ( ‘:’ ) and a value whose structure depends upon the header. The whole header, including the value, consist of one single line, which can be quite long.

Many different headers can appear in requests. They can be divided in several groups:

Bodies can be broadly divided into two categories:

HTTP Responses

Status line

The start line of an HTTP response, called the status line, contains the following information:

Headers

HTTP headers for responses follow the same structure as any other header: a case-insensitive string followed by a colon ( ‘:’ ) and a value whose structure depends upon the type of the header. The whole header, including its value, presents as a single line.

Many different headers can appear in responses. These can be divided into several groups:

The last part of a response is the body. Not all responses have one: responses with a status code that sufficiently answers the request without the need for corresponding payload (like 201 Created or 204 No Content ) usually don’t.

Bodies can be broadly divided into three categories:

HTTP/2 Frames

HTTP/1.x messages have a few drawbacks for performance:

HTTP/2 introduces an extra step: it divides HTTP/1.x messages into frames which are embedded in a stream. Data and header frames are separated, which allows header compression. Several streams can be combined together, a process called multiplexing, allowing more efficient use of underlying TCP connections.

HTTP frames are now transparent to Web developers. This is an additional step in HTTP/2, between HTTP/1.1 messages and the underlying transport protocol. No changes are needed in the APIs used by Web developers to utilize HTTP frames; when available in both the browser and the server, HTTP/2 is switched on and used.

Conclusion

HTTP messages are the key in using HTTP; their structure is simple, and they are highly extensible. The HTTP/2 framing mechanism adds a new intermediate layer between the HTTP/1.x syntax and the underlying transport protocol, without fundamentally modifying it: building upon proven mechanisms.

Как исправить ошибку HTTP 302 (Moved Temporarily)

Ошибки Moved Temporarily

Распространенные проблемы, связанные с Edge s, возникающие с Moved Temporarily:

Источник ошибок Moved Temporarily

Особенно эти ошибки Moved Temporarily проистекают из:

Совместима с Windows 2000, XP, Vista, 7, 8, 10 и 11

I’m trying to send a post request in Flutter with DIO package.

Here is the request:

After the request i get:

From this request i only need to get the sessionid cookie, but the function stop with unhandled exception.

6 Answers 6

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

I solved this way:

Add followRedirects: false and validateStatus: (status) < return status to the request. Like this:

This way you can get from the 302 every headers and other.

The Dart HTTP client won’t follow redirects for POSTs unless the response code is 303. It follows 302 redirects for GET or HEAD.

You could see if you can stop the server sending the redirect in response to a (presumably) valid login request, and send a 200 instead.

Or you could try sending the login request as a GET by encoding the form fields into the URL, for example:

You would have to URL encode any special characters in the parameters. Presumably, you’ll want to use HTTPS too.

Status code 302

Коды состояния HTTP, разделены на 5 категорий. Клиент может быть не знаком с тем или иным кодом ответа HTTP, однако он должен отреагировать согласно категории кода. Итак протокол HTTP поддерживает следующие коды статуса, разделенные по категориям:

Некоторые клиенты некорректно работают с редиректами 301 и 302, применяя в запросе ко второму ресурсу метод GET, несмотря на то, что первый запрос был сделан с использованием другого метода. В протоколе HTTP версии 1.1, вместо ответа статуса 302, были введены дополнительные коды ответов, 303 и 307. Изменять метод, необходимо только в случает ответа сервера со статусом 303, в остальных случаях использовать исходный метод.

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

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

Если решение вопроса найти не удалось, Вы можете отправить нам заявку:

Http Status Code

A status code is a part of the response returned by the server when a client (e.g., a browser) calls a URL. With the help of a status code, the server tells the client whether the request was successfully processed or whether an error occurred.

Contents

Status classes

The three-digit HTTP status codes can be classified in different status classes, where the first digit stands for the respective status class.

Check HTTP status codes

Normally, the web browser does not show the status code. Therefore, you have to use special tools to monitor these. Browser extensions are a good way of monitoring HTTP status codes such as using Live Http-Headers or using special online tools like Web-Sniffer.

Status code 100

Status code 100 is returned if the server has correctly received a request and is now waiting for further instructions from the client. Only then can the request be executed by the server.

Status code 102

This processing status code is used to prevent a timeout during the request. This can happen especially if the server has to process a time-consuming request.

Status code 2xx – successful operation

Status code 200

Status code 200 is returned by the server if the data requested by the client (e.g., web browser) were transmitted as desired. Here, the following requirements usually have to be met:

If these requirements are met, the requested data are sent to the client and the status code 200 OK is included in the response.

Status code 200 is one of the most commonly occurring status codes as it represents the normal case. The status code is returned when there are no problems.

Status code 301

Status code 301 shows that the resource requested by the client is no longer available at the given address but has rather been permanently moved to another address (redirect). The old address of the resource is henceforth no longer valid. The new address is sent back to the requesting client, enabling the client to retrieve the resource at the new address.

The difference between status code 301 and the very similar status code 302 lies in the time designation. While the old address remains valid if status code 302 is returned, the old address is no longer valid if status code 301 is returned. The 301 redirect thereby inherits the link juice, whereas this is not the case with 302.

Use case – URL change

In the best case scenario, a once assigned URL structure remains unchanged forever. However, if it becomes necessary to change the URL structure of a page or to change its domain, it must be ensured that all the old URLs are redirected to the new URL. This particularly applies to URLs that have acquired valuable external links over time. This is done using a 301 redirect. In this case, if the no longer existing URL is called, the server returns the status code 301 and informs the client of the new URL of the resource. According to the RFC standard, an absolute URL should be used in a redirect. Thus, relative redirects are not valid.

There are different ways of sending status code 301. For example, when using PHP-based applications, a corresponding header can be generated. To do this, the following PHP code must be added in the old file:

When using the status code 301, it should be ensured that all pages are redirected 1:1 to the new subpages and not to the homepage in case of a domain change. Furthermore, the so-called routing loops or long routing chains should be avoided. Googlebot usually switches off after the fourth or fifth redirection.

Redirection of links

A 301 redirect redirects most of the link juice to the new destination but not the reputation of the page on Google Plus (social signals). Before moving the content, one should first check whether the redirection is really desirable.

Status code 302

Status code 302 Found shows a temporary redirect. This means that the requested resource can temporarily be found at another address. In addition to this status code, the server also returns the new address of the resource. One important difference to Status Code 301 is that the original address remains valid. This is also the reason why contents that are permanently accessible at a new address should be delivered with status code 301 and not status code 302. This is because Googlebot continues to search through and index the original location during the temporary redirection. It is also important to ensure that no link juice is inherited with status code 302 but rather with status code 301.

Status code 400|Status code 4xx – client error

Status code 404

Status code 404 Not Found is always returned when the requested resource (mostly a URL but can also be an image or other file) does not exist or no longer exists, and is, together with the Status Code 200 “OK” and the 304 “Not Modified”, one of the most common HTTP status codes.

Reasons for the 404 status code

A non-existent resource can arise if:

Rectifying the 404 error

Soft 404 errors

Soft 404 errors are encountered in websites that no longer provide the requested content nor return the 404 or 410 status code. In such cases, the webmaster has not provided any 404 error page, so that status codes “200 Ok” or “302 Found” are issued when visiting the pages.

In practice, there is little point when users search for specific content but are shown a page that does not show any error code and instead displays content that does not match the query. Google itself recommends the use of the 404 status code when the content is no longer hosted on a page. [1] For better usability, the error page can be optimized to persuade the users to stay on the website.

Common SEO tools, Google Search Console, or the Bing Webmaster tools can be used to analyze soft 404 errors.

Status code 5xx – server error

Status code 500

Status code 503

Status code 503 shows a temporary unavailability of the server. This can be as a result of several reasons. For example, this status code can be shown during maintenance or overload of the server. A “retry after” header field can be added to inform the client of the corresponding time when the sent request can be processed. It should hereby be noted that with status code 503, the server does not process the request even after the respective capacities are available again.

Status code 9xx – proprietary status codes

Status code 906

This status code is provided if an error occurs during transmission of the request from the client to the remote server. The request must be sent again.

Status code 950

Status code 950 is returned if an error occurs in the interpretation of an administrative request of the client. Here as well, the request must be sent again in most cases.

Significance of status codes for search engine optimization

The http status codes play an important role in search engine optimization. A high frequency of 404 errors can indicate a badly maintained website. If users receive the status code 404 when they access URLs, this leads to a higher bounce rate, which in turn represents a negative user signal for Google and other search engines.

The indication «404-not found» is a natural part of the web, if a page is no longer available, for example due to a domain transfer. Soft 404 errors, on the other hand, have a greater effect on search engine optimization. You deliver a status code that does not match the content of the page. In the worst case, Soft 404 errors can lead to the exclusion of a URL from the Google index.

Also important for the SEO are 301 redirects because they help prevent duplicate content.

How to handle 301, 404, 503 and other scary HTTP numbers

HTTP status codes are like brief notes from servers that are put on top of web pages, but aren’t in fact a part of them. What they are, are messages from servers that notify you how different requests are received by servers.

Basically, whenever browsers interact with servers, such messages are returned. However, users may not see them at all in many cases. But if you own or optimize websites, it’s critically important for you to understand HTTP status codes. They’re crucial when it comes to diagnosing and patching up various configuration errors on your website.

In this blog post, we’ll look at the most common HTTP status codes and errors, as well as explain how to handle them to avoid making a mess of your website.

Side-note: If you want to check the status codes of your site’s web pages, plus get a detailed SEO audit, you’re welcome to make use of our Website Audit tool.

What status code classes are there?

Each request has HTTP server response data that includes a three-digit number that specifies the request’s result. These response codes are broken down into 5 distinct classes. Let’s quickly go through each one of them:

I want to draw your attention to the fact that not every status and error code can be seen, in fact, most of them aren’t shown to users at all. However, you can check them by inspecting a page via your browser (Ctrl+Shift+C to open the Chrome Developer Tools in Inspect Element mode). Just go to the Network tab and refresh the page to get a list of the statuses of each element on the page, including the page itself:

Now, let’s take a close look at the most common server responses and how they need to be handled.

Common HTTP Status Codes

Before we continue, I want to point out that there are more than 40 different server status codes, but it’s likely that you won’t run into more than a handful of them in your work. So, if you’re in charge of a website and its SEO processes, it’s imperative that you understand them so that you know what to do when you’re faced with HTTP status code issues.

Without further ado, here’s a list of the most common HTTP status codes:

301 Moved Permanently

The HTTP 301 Moved Permanently status code indicates that the URL requested by the client has been moved to a new location. Browsers follow 301 redirects without asking users to perform an action.

The 301 status code is typically used when switching a website from HTTP over to HTTPS, but it is also employed when setting up access to the website mirror, during URL trailing slash configuration, as well as when transferring a part of the site or the entire website to a new domain.

This redirect is highly recommended if your goal is to transfer the SEO ranking and authority of an old web page to a new one. But simply changing the URL without updating content will have a negative impact on the indexation of new changes. Think about it: You send a new signal to search engines that you want the new page to come up in search, but since the old URL has a lot of authority, Google doesn’t want to replace it with the new page.

Pro Tip: Don’t ever redirect users from a deleted URL to your homepage. Such redirects are treated as soft 404s by Google, meaning that the search giant won’t pay any attention to them, won’t pass the PageRank or any other signals from the old URL to the new one. Instead, lead users to a page that’s similar to the destination page.

Additionally, avoid redirect loops as they prevent users from getting to the target page. In other words, steer clear of using link chains that include a link that’s redirected to a URL that’s already part of the same chain.

Plus, Google doesn’t index beyond the 4th or even 3rd redirect in a redirect chain. For this reason, it’s important not to use multiple redirects as each new one will result in a ranking weight loss. Multiple redirects will confuse Google as to where all of the page authority should be directed. So, just cut out the middleman and redirect the first page directly to the last one you have set up. On top of that, you can even remove 301 redirects as time passes to reduce the server load.

302 Found

The 302 Found status code is very similar to the 301 code, but the 302 status code was created for situations when a website isn’t moved permanently, but only temporarily.

Basically, browsers follow the 302 code automatically, and it indicates that the page was successfully found, but it has been temporarily moved to a new location. As a general rule, it should only be used for short content maintenance processes, when you ultimately intend to take your website visitors back to the old web page.

When you set up the 302 redirect, you tell search engines that you plan on using the old URL again in the future. As a result, the temporary new page doesn’t get any traffic value or page authority from the original URL.

Pro Tip: If you leave the 302 redirect in place for too long, Google will end up treating it as if it’s a 301 redirect. Furthermore, make sure to check that your website doesn’t have any 302 redirects that are supposed to be 301 as this is a very common mistake.

304 Not Modified

The browser sees the 304 Not Modified HTTP status code when a web page is up to date with the cached copy on the server. Essentially, this means that the page hasn’t changed since the last visit.

To elaborate, when browsers store data in their cache, they store the Last-Modified header data as well. In turn, this enables browsers to know exactly when the page was last modified. And when search engines look at the page and see that both header values are the same, the server returns the 304 code.

This code can actually be used to speed up website indexation. For example, as crawlers are going through your website, they’ll stumble upon multiple pages. And if they learn that one or several pages have not been changed in any way, they’ll skip them, ultimately, enabling more pages to get indexed.

Pro Tip: Every SEO expert is expecting to see the 200 OK status code as an indication that the request is successful, but the 304 status code basically means the same thing. As a rule of thumb, new pages and first page visits should get the 200 code, and every subsequent visit should produce the 304 code.

403 Forbidden

The 403 Forbidden status code indicates that the user doesn’t have permission to access the requested web page. This one is pretty straightforward.

There are several reasons why this status code can appear. For example, the user is logged into the website, but doesn’t have the necessary permission to access its closed-off internal network.

Other cases when the 403 status code can appear include situations when the index file for the main page is incorrect. The index file should be called “index” and have the *.shtml, *.html, *.htm, *.phtml or *.php extensions, so make sure to check that that’s the situation in your case.

Moreover, when you switch over to HTTPS, the 403 status code may appear if the Domain Name System (DNS) cache hasn’t been updated yet. Best practices suggest you wait until the cache gets updated, but if it’s a matter of life and death, clear your DNS cache immediately.

Pro Tip: Pages that produce the 403 response code will ultimately be removed from the index, which is why Google advises to use the 404 status code for this instead.

404 Not Found

Probably one of the most well-known status codes in SEO is the 404 Not Found error. This code indicates that the server hasn’t found anything matching the requested URL, but a network connection between the server and the client has successfully been established.

Now, don’t worry if you see a lot of 404 pages in your Google Search Console account. Google is simply letting you know which pages are deleted and it’s up to you to check if everything’s okay. But make sure to remove every link to the deleted pages from your site, so that you don’t confuse visitors as they navigate it.

We usually see this error code when we manually enter a wrong URL into the browser and, as a result, try to access a page that doesn’t exist. However, it can also appear if the server admin deleted a file without first redirecting the URL to a new location that’s valid. To solve the problem, you need to check the requested URL, fix it yourself or wait for the admin to do it.

Pro Tip: Pages that display the 404 status code aren’t indexed and don’t pass any authority, which is why some SEO experts employ a soft 404 page instead that returns a page notifying users that the page doesn’t exist along with the 200 status code. But this is considered bad practice because the success code tells Google that there’s a real page at that URL. Ultimately, the page may end up getting listed in SERPs, and the search giant will continue its attempts to crawl non-existent URLs instead of crawling your actual pages.

Setting up the 404 page for your site

The 404 page used to look like a solid wall of code, but now that times have changed, it has become a lot more creative. However, you must keep in mind that users came to your web page with a specific request, and your job isn’t just to entertain them with cool images, but to help them find what they’re looking for. So, make sure to add your website navigation or a contact form to your 404 pages, especially if they are still seeing traffic.

Now, if your content management system didn’t generate a 404 page for your website, you can create one yourself. Here’s how you can do it:

404 page via htaccess

The simplest way to set up a 404 error page on your website is by directly entering the error message, such as ErrorDocument 404 “

Not Found

404 page via PHP

As for creating a 404 page via PHP, in a nutshell, you can use the header function.

404 page via WordPress

You have several options when it comes to creating a custom 404 page in WordPress:

You can get all of the details on how to do it here.

410 Gone

The 410 Gone status code indicates that the requested website is no longer available on the server and no forwarding address is known. And because Google’s URL Inspection Tool labels 410 codes as 404 as well, you’ll end up seeing even more 404 page errors in your Google Search Console.

This status code is typically used on pages that have low trust, don’t have any links as well as on permanently deleted ones. For example, let’s say you no longer offer a particular service on your website and want to stop driving traffic that’s searching for the non-existing page. This is where the 410 status code comes into play.

Since Google doesn’t technically treat 404 and 410 errors the same way, you can use a temporary custom 410 page to provide search engine robots with a more accurate status and information that the old link should be removed from the crawl index. Consequently, this can stop the inflow of unnecessary, irrelevant traffic.

But do think twice before permanently taking down a page. If you’re not sure, you can always set up a redirect and still see some traffic. However, if you do decide to completely kill a page, be on the lookout for links that link out to the soon-to-be-deleted page that will break once the page’s removed.

503 Service Unavailable

The 503 Service Unavailable status code indicates that the website server is currently unavailable and, consequently, cannot process the incoming client request.

In the vast majority of cases, the 503 status code appears if the server is too busy, as in it’s exceeding the limit on the number of concurrent users, or if the server’s undergoing maintenance works.

It can also be used in other cases, for example, if:

Ideally, the 503 page should contain a message that specifies the exact time when the visitor should come back, but this is rarely the case.

Last but not least, the 503 status code blocks search engines from indexing the site. Additionally, it signals to search engines that the site is poorly maintained because users can’t find what they’re looking for. Therefore, it’s important that such issues are solved as quickly as possible. Otherwise, it will affect your overall search rankings.

Setting up the 503 page via PHP

Here’s what the 503 status code looks like in PHP:

Here you can read up about it in full detail.

Checking the server response with the Website Audit

To stay on top of everything that’s going on with your website, you must always keep an eye on your web pages and monitor their status codes. Sure, you can use the Live HTTP Headers extension for Chrome and the Index Coverage report in Google Search Console to view the status codes of your web pages, but it’s better if you spot and analyze them before the search engines do.

To do this, you can also make use of SE Ranking’s Website Audit.

In addition to being able to pinpoint and quickly identify website errors, the Website Audit tool also generates a list of suggestions that can help developers, content creators, and web designers do their job accurately.

By the way, you’re welcome to take advantage of the free trial to try out all of the features.

As you scroll through the audit report, you’ll see a detailed breakdown of everything that’s right and wrong with your website, including its SEO health, page, meta, content and link analysis. The best part is that you can easily find out if your site has any pages with an unexpected status code.

Just go to the Crawled Pages tab to analyze your page status codes, without any distractions — either directly in the platform or by exporting an XLS file:

You will still have to implement the changes manually, but finding them will no longer be a daunting task. Once you optimize the status codes of your web pages using the Website Audit, let Google know so that it can check and update them for everyone to see!

To help you out, we’ve put together a cheat sheet that outlines some HTTP status code SEO best practices:

Список кодов состояния HTTP

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Тем не менее, известно о двух используемых кодах, не упомянутых в RFC: 449 Retry With [прим 1] (введён Microsoft) и 509 Bandwidth Limit Exceeded (введён в cPanel).

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

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

Обзорный список

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

1xx: Informational (Информационные)

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

100 Continue (Продолжать)

Появился в HTTP/1.1.

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

101 Switching Protocols (Переключение протоколов)

Появился в HTTP/1.1.

Сервер предлагает перейти на более подходящий для указанного ресурса протокол. Список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола.

102 Processing (Идёт обработка)

Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме.

2xx: Success (Успешно)

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

200 OK (Хорошо)

Появился в HTTP/1.0.

Успешный запрос ресурса. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения.

201 Created (Создано)

Появился в HTTP/1.0.

В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ 202.

202 Accepted (Принято)

Появился в HTTP/1.0.

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

203 Non-Authoritative Information (Неавторитетная информация)

Появился в HTTP/1.1.

Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной.

204 No Content (Нет содержимого)

Появился в HTTP/1.0.

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

205 Reset Content (Сбросить содержимое)

Появился в HTTP/1.1.

Сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно.

206 Partial Content (Частичное содержимое)

Появился в HTTP/1.1.

Сервер удачно выполнил частичный GET возвратив только часть. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию.

207 Multi-Status (Многостатусный)

Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности.

226 IM Used (IM использовано)

Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров.

3xx: Redirection (Перенаправление)

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

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

См. так же пример перенаправлений в статье по HTTP.

300 Multiple Choices (Множество выборов)

Появился в HTTP/1.0.

По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту (автоматически) или пользователю.

301 Moved Permanently (Перемещено окончательно)

Появился в HTTP/1.0.

Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Учтите что некоторые клиенты некорректно ведут себя при обработке данного кода (см. описание ко всему классу 3xx).

302 Found (Найдено)

Введено в HTTP/1.0.

Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Учтите что некоторые клиенты некорректно ведут себя при обработке данного кода (см. описание ко всему классу 3xx).

303 See Other (Смотреть другое)

Введено в HTTP/1.1.

Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET (см. описание ко всему классу 3xx).

304 Not Modified (Не изменялось)

Появился в HTTP/1.0.

Сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела.

305 Use Proxy (Использовать прокси)

Введено в HTTP/1.1.

Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси).

306 (зарезервировано)

Упомянуто в RFC 2616 (обновление HTTP/1.1).

Использовалось раньше, в настоящий момент зарезервировано.

307 Temporary Redirect (Временное перенаправление)

Введено в RFC 2616 (обновление HTTP/1.1).

Запрашиваемый ресурс короткое время доступен по другому URI (указывается в поле Location заголовка). Этот код был введён вместе с 303 вместо 302-ого для избежания неоднозначности (см. описание ко всему классу 3xx).

4xx: Client Error (Ошибка клиента)

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

400 Bad Request (Плохой запрос)

Появился в HTTP/1.0.

Запрос не понят сервером из-за наличия синтаксической ошибки. Клиенту следует повторно обратиться к ресурсу с изменённым запросом.

401 Unauthorized (Не авторизован)

Появился в HTTP/1.0.

Запрос требует идентификации пользователя. Сервер должен запросить имя и пароль у пользователя, а тот передаст их в заголовке WWW-Authenticate в следующем запросе. Если были указаны неверные данные, то сервер снова вернёт этот же статус.

402 Payment Required (Необходима оплата)

Зарезервирован начиная с HTTP/1.1.

Предполагается использовать в будущем. В настоящий момент не используется.

Обратите внимание что этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Если не оплачена услуга хостинга сайта, то логичней возвращать клиенту ответ из класса 5xx. Например, как cPanel возвращает ответ 509 (Bandwidth Limit Exceeded) когда площадкой превышен лимит на потребление трафика.

403 Forbidden (Запрещено)

Появился в HTTP/1.0.

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

Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 (или 407 для прокси). В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого ПО.

В любом случае клиенту следует сообщить причины отказа в обработке запроса.

Наиболее вероятными причинами ограничения могут послужить:

404 Not Found (Не найдено)

Появился в HTTP/1.0.

Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы.

405 Method Not Allowed (Метод не применим)

Появился в HTTP/1.1.

Указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow разделив их запятой.

Обратите внимание что эту ошибку сервер должен возвращать если метод ему известен, но он не применим именно к указанному в запросе ресурсу. Если же указанный метод не применим на всём сервере, то клиенту нужно вернуть ответ 501 (Not Implemented).

406 Not Acceptable (Не приемлемо)

Появился в HTTP/1.1.

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

407 Proxy Authentication Required (Необходима авторизация прокси)

Появился в HTTP/1.1.

Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере.

408 Request Timeout (Время ожидания истекло)

Появился в HTTP/1.1.

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

Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать (например, из-за повреждёния компакт-диска или потеря связи с другим компьютером в локальной сети). Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны чтобы дать возможность другим клиентам сделать запрос.

Разумеется, этот ответ не возвращается когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать не возможно.

409 Conflict (Конфликт)

Появился в HTTP/1.1.

Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.

410 Gone (Удалён)

Появился в HTTP/1.1.

Такой ответ сервер посылает, когда ресурс раньше был по указанному URI, но был удалён и теперь недоступен. Серверу в этом случае не известно и местоположение альтернативного документа (например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404.

411 Length Required (Необходима длина)

Появился в HTTP/1.1.

Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI.

Такой ответ вполне естественнен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку разрывая соединение когда клиент действительно пришлёт слишком объёмное сообщение.

412 Precondition Failed (Условие «ложно»)

Появился в HTTP/1.1.

Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.

413 Request Entity Too Large (Запрашиваемые данные слишком большие)

Появился в HTTP/1.1.

Возвращается если сервер по каким-то причинам не может передать запрашиваемый объём информации. Если проблема временная, то сервер может в ответе указать в поле Retry-After время, по истечении которого можно повторить аналогичный запрос.

414 Request-URI Too Long (Запрашиваемый URI слишком длинный)

Появился в HTTP/1.1.

Сервер не может обработать запрос из-за слишком длинного указанного URI. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST.

415 Unsupported Media Type (Неподдерживаемый тип данных)

Появился в HTTP/1.1.

По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе.

416 Requested Range Not Satisfiable (Запрашиваемый диапазон не достижим)

Введено в RFC 2616 (обновление HTTP/1.1).

В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges.

417 Expectation Failed (Ожидаемое не приемлемо)

Введено в RFC 2616 (обновление HTTP/1.1).

По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса.

422 Unprocessable Entity (Необрабатываемый экземпляр)

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

423 Locked (Заблокировано)

Целевой ресурс из запроса заблокирован от применения к нему указанного метода.

424 Failed Dependency (Невыполненная зависимость)

Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт код 424.

425 Unordered Collection (Неупорядоченный набор)

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

426 Upgrade Required (Необходимо обновление)

Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.

Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection.

449 Retry With (Повторить с. )

Возвращается сервером если для обработки запроса от клиента поступило не достаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request.

В настоящий момент как минимум используется программой Microsoft Money. Более подробную информацию по данному коду ответа можно получить в библиотеке MSDN.

5xx: Server Error (Ошибка сервера)

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

500 Internal Server Error (Внутренняя ошибка сервера)

Появился в HTTP/1.0.

Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса 5xx.

501 Not Implemented (Не реализовано)

Появился в HTTP/1.0.

Сервер не поддерживает возможностей, необходимых для обработки запроса.

Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим только к данному ресурсу, то нужно вернуть ответ 405 (Method Not Allowed).

502 Bad Gateway (Плохой шлюз)

Появился в HTTP/1.0.

Сервер в роли шлюза или прокси получил сообщение о неудачном выполнении промежуточной операции.

503 Service Unavailable (Сервис недоступен)

Появился в HTTP/1.0.

Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным является сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов.

504 Gateway Timeout (Шлюз не отвечает)

Появился в HTTP/1.1.

Сервер в роли шлюза или прокси не дождался ответа от вышестоящего сервера для завершения текущего запроса.

505 HTTP Version Not Supported (Версия HTTP не поддерживается)

Появился в HTTP/1.1.

Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.

506 Variant Also Negotiates (Вариант тоже согласован)

Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

В результате ошибочной конфигурации выбранный вариант указывает сам на себя из-за чего процесс связывания прерывается.

507 Insufficient Storage (Переполнение хранилища)

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

509 Bandwidth Limit Exceeded (Исчерпана пропускная ширина канала)

Введено в расширении bw/limited (mod_bwlimited) к Apache для cPanel.

Используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем bw/limited, входящем в панель управления хостингом cPanel.

510 Not Extended (Не расширено)

Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

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

Интересные факты

Примечания

Источники

См. также

Ссылки

Основные документы по протоколу HTTP (по убыванию даты публикации):

Документы по расширениям и обновлениям протокола HTTP (по убыванию даты публикации):

Status code 302

Чтобы страница сайта была проиндексирована, нужно чтобы на нее зашел поисковый робот. Каждая страница сайта всегда отдает так называемый «статус-код» по которому поисковый робот может определить индексировать страницу или нет.

Что такое статус-код страницы

Статус-код – это сообщение, которое возвращается при обращении к серверу, и позволяет узнать состояние веб-страницы. Статус-код состоит из трех десятичных цифр и представляет собой целое число.

Статус-коды разделяют на 4 группы:

2xx (двухсотые статус-коды) – коды успешных запросов

3xx (трехсотые статус-коды) – коды перенаправления (редиректы)

4xx – коды http-ошибки (самая известная – 404 ошибка или «страница не найдена»)

5xx – коды ошибок сервера

Коды статуса 200

200 ОК – это код, который возвращается при обращении к серверу, когда со страницей все в порядке и ресурс работает точно так, как ожидается.

Если страница имеет статус код 200, то она попадает в индекс.

Все страницы сайта по-хорошему должны иметь статус-код 200 ОК, но на практике так почти никогда не бывает.

Коды статуса 300

Коды статуса 300 – это статусы перемещений (или редиректов)

Самые распространенные в этой группе 301 и 302 редиректы.

301 редирект

301 редирект – страница (ресурс) была перемещена навсегда. Или перемещение старых страниц на новые.

Такой код возвращается, когда одна страница заменяется другой страницей. Используется для постоянного перенаправления url-адресов (редиректов).

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

302 редирект

302 редирект – запрошенный ресурс был перемещен временно.

Используется для временных редиректов url-адресов. Например, у вас интернет-магазин и вы хотите сделать так, чтобы все незарегистрированные пользователи когда нажимали на кнопку «купить товар» попадали не в корзину, а на страницу с регистрацией. В этом случае помогает 302-редирект. Получается, что подобное перенаправление срабатывает не всегда, а лишь тогда, когда на сайте пользователь не зарегистрирован и не авторизирован.

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

Как настроить 301 редирект

301 редирект с одной страницы на другую

Это самый распространенный редирект. Пример:

301 редирект с домена на домен

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

301 редирект с http на https

Когда ваш сайт переезжает с протокола http на https, обязательно нужно настроить редирект. Очень грубая ошибка многих разработчиков в том, что они настраивают редиректы с одного протокола на другой, забывая www. Данный процесс называется настройкой зеркал сайта (или склейкой зеркал сайта).

Настроить главное зеркало с помощью 301 редиректа

Поисковые системы считают дублями страницы, если они открываются по разным протоколам (http, https) и также если страницы открываются с www и без него. Если у сайта существует несколько копий, то следует выбрать и прописать главное зеркало.

Ниже приведен пример 301 редиректа при переезде сайта с http на https в трех вариантах (для разных сайтов и CMS может подойти один из предложенных):

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

Коды статуса 400

Коды статуса 400 – коды ошибок

403 – Доступ к ресурсу запрещен. Данный статус код возвращается, когда пользователь пытается открыть ресурс, но у него нет прав доступа. Например, когда ресурс защищен паролем.

404 – Запрошенный ресурс не найден.

Самое распространенное сообщение об ошибке, которое видел каждый на разных сайтах.

Данный код возвращается когда страница (или ресурс) не существуют и сервер не знает существовал ли он когда-либо.

Коды статуса 500

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

503 – это код, который возвращается, когда сервер не может обработать запрос.

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

Проверка статус-кода

После проведения всех настроек, необходимо проверить статус код страниц.

Есть несколько сервисов, которые мы рекомендуем использовать не только для проверки статус-кодов, но и для полноценного seo-продвижения:

What happens when a browser encounters a 302 header status code?

Does the browser make a new request to the location given in the header?

I ask because I was playing around with Fiddler and noticed when I make a request to a page that returns a 302 HTTP code, there are two entries in the network log. The first is to the initial URL, and the second is to the new location given in the response header of the first request.

I’m just curious if web browsers work the same way, but just hide the first response from the user.

1 Answer 1

Yes, the browser works in very much similar fashion. You can try requesting a url in Chrome, possibly the one you tried in Fiddler. The Network Log of chrome would show you two requests.

The RFC description of HTTP status code can be read over here,

Quoting from there only, regarding the 302 status code:

RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

When a server responds with a 302 status code, it send back the newer url (to which the current requested old url is to be redirected) to the requesting user-agent (likely a browser). Now, as per the RFC document, the user agent must not request the newer url for 302 status code. Yet most of them do make a second request.

Коды состояния HTTP и что они значат для SEO (перевод)

Коды состояния HTTP, такие как 404, 301 и 500, едва ли имеют значение для пользователей, но для оптимизаторов они невероятно важны. Мало того, что роботы поисковых систем (как Googlebot) используют их для определения здоровья сайта, коды состояния помогают узнать, что происходит между браузером и сервером. Некоторые из них указывает на ошибку, например, сигнализируют о том, что запрошенное содержимое не может быть найдено, в то время как другие просто выводят запрашиваемый материал. В этой статье мы пристальнее посмотрим на важнейшие коды HTTP заголовков и узнаем, что они означают для SEO.

Что такое коды состояния HTTP и почему вы их видите?

Код состояния HTTP – это сообщение, которое посылается сервером при отправке запроса с браузера, о том, может ли быть выполнен запрос или нет. Согласно официальной спецификации W3C, существуют десятки кодов состояния, со многими из которых вы вряд ли столкнетесь. А если столкнетесь, полный обзор возможных вариантов можно посмотреть на HTTPstatuses.com.

Чтобы понять эти коды, вам стоит знать, как браузер получает веб-страницу.

Добраться до веб-сайта пользователь может двумя способами – набрав URL сайта или введя запрос в строке поиска. После этого браузер посылает запрос на IP-адрес сайта, для получения соответствующей веб-страницы. Сервер отвечает браузеру, отправляя код состояния, встроенный в заголовок HTTP. Когда все нормально, код заголовка HTTP 200 отправляется обратно в браузер, вместе с запрошенным контентом.

Однако с запрашиваемым контентом или сервером что-то может быть не так. Например, не найдена страница (тогда возвращается код ошибки 404) или есть временная техническая проблема с сервером, в результате чего появляется код внутренней ошибки сервера 500. Эти коды статуса HTTP – важные инструменты для оценки состояния здоровья сайта и его сервера. Если сайт регулярно посылает неправильные коды заголовка HTTP в поисковую систему, его содержимое не индексируется, что, в свою очередь, вредит рейтингу.

Различные классы

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

Наиболее важные коды состояния HTTP для SEO

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

200: OK / Успешно

Вот как должно быть: клиент запрашивает у сервера контент и сервер отвечает сообщением 200. Это означает, что запрос прошел успешно – браузер получает содержимое, которое удовлетворяет потребностям клиента. И сервер, и клиент довольны. Пользователь счастлив. Все сообщения класса 2xx означают успешное выполнение какой-либо операции.

301: Перемещено навсегда

Заголовок HTTP 301 используется, когда запрашиваемый URL перемещен на новое место. Поскольку вы работаете с сайтом, с кодом придется сталкиваться часто – чтобы перенаправить старый URL на новый, вам обязательно нужно делать 301 редирект. Если вы этого не сделаете, пользователи, открывая старый URL, увидят страницу с кодом ошибки (404).

302: Найдено

Код состояния HTTP 302 означает, что целевой контент был найден, но находится в другом месте. Это довольно неоднозначный код состояния – он не говорит, временная это ситуация или нет. Используйте 302 редирект только в том случае, если хотите временно перенаправить URL на другой источник, и вы уверены в том, что будете использовать URL снова. Этим кодом вы сообщаете поисковым системам, что URL-адрес будет использоваться, а значит ссылочный вес не перенесется на новый URL. Поэтому не пользуйтесь 302 редиректом при перемещении домена или серьезных изменениях в структуре сайта.

307: Временное перенаправление

Код состояния 307 заменяет 302 в спецификации HTTP1.1 и может рассматриваться как единственный истинный редирект. Вы можете использовать 307 если вам нужно временно перенаправить URL на новый, оставив оригинальный метод запроса без изменений. 307 выглядит как 302, за исключением того, что он конкретно сообщает о временном характере нового местоположения. Запрос может меняться с течением времени, поэтому клиент должен продолжать использовать оригинальный URL при создании новых запросов.

403: Запрещено

403 сообщает браузеру, что запрошенное содержимое запрещено для пользователя. Если пользователь не сможет предоставить корректные учетные данные для входа, содержание останется недоступным.

404: Не найдено

Код заголовка HTTP 404 – один из наиболее важных. Когда сервер дает ответ в виде ошибки 404, вы получаете информацию о том, что содержимое не было найдено, и, вероятно, удалено. Старайтесь не раздражать посетителей сообщениями с этим кодом, исправляйте ошибки как можно скорее. Используйте редирект для перенаправления посетителей сайта со старого URL на новую статью или страницу, которая имеет связанный контент.

Мониторьте 404 сообщения в интерфейсе ошибок (Crawl errors) Google Search Console и пытайтесь свести их количество к минимуму. Большое количество ошибок этого типа может быть расценено Google как признак плохого обслуживания, а это повлияет на рейтинг сайта.

410: Удален

Результат кода 410 такой же, как 404 – содержимое не было обнаружено. Тем не менее, с 410 вы сообщаете поисковым системам об удалении запрошенного содержимого. Таким образом, этот код намного конкретнее 404. В некотором смысле вы отдаете команду поисковой машине удалить URL из индекса. Перед тем, как окончательно удалить что-то с сайта, подумайте, есть ли где-нибудь эквивалент страницы. Если да, сделайте редирект. Если нет, страницу нужно удалить или улучшить.

451: Информация недоступна по юридическим причинам

Относительно новое дополнение. Код состояния HTTP 451 показывает, что запрошенное содержимое было удалено по юридическим причинам. Если вы получили запрос на удаление, нужно использовать этот код, чтобы сообщить поисковым системам, что случилось со страницей.

500: Внутренняя ошибка сервера

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

503: Сервис недоступен

Сервер отправляет сообщение об ошибке 503, когда не может обработать запрос из-за сбоя или перегрузки. Используйте этот код всякий раз, когда вам требуется временный простой – например, когда вы проводите обслуживание сайта. Таким образом, роботы поисковых систем узнают, что ваш сайт вскоре возобновит работу, и они могут вернуться позже.

Работа с кодами состояния HTTP

Коды HTTP – важная часть деятельности оптимизаторов. Вы будете сталкиваться с ними ежедневно, и поэтому важно понять, что означают различные коды. Например, при удалении страницы с сайта важно знать разницу между 301 и 410 редиректом. Они служат для разных целей, и, следовательно, ведут к разным результатам.

Если вы хотите получить представление о видах кодов состояния, которые генерирует ваш сайт, войдите в Google Search Console. Здесь вы найдете страницу с ошибками сканирования. Они должны быть найдены и устранены, прежде чем ваш сайт будет проиндексирован.

В заключение

Помните об этих кодах, при работе с сайтом вы увидите как часто они появляются. Зная, какие редиректы нужно использовать в той или иной ситуации, вы сможете спасти свой сайт от необязательных потерь позиций в ранжировании. Одного взгляда на ошибки при сканировании в Google Search Console должно быть достаточно, чтобы вы получили достаточно точные данные о происходящем под капотом.

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

Как это сделать? Откройте Google Search Console. Перейдите во вкладку «Crawl» > «Crawl Errors». Там вы сможете посмотреть, что происходит с сайтом и уладить проблемы.

В первую очередь разберитесь с внешними ссылками, ведущими на страницу. Google, как правило, сортирует ошибки по важности. Ошибки с внешними ссылками относятся к приоритетным. Чтобы посмотреть, откуда идет ссылка, кликнете по URL-адресу 404 страницы. В открывшейся вкладке выберите «Linked From» и посмотрите URL-ссылки на страницу. Убедитесь, что все 404 страницы перенаправлены 301 редиректом на релевантный URL.

Проверять сайт на наличие ошибок нужно часто. Делайте это хотя бы раз в месяц.

Код HTTP 404 особенно важен, потому что его чаще всего видят пользователи. Ваша задача – обеспечить лучший пользовательский опыт, поэтому обязательно оформите страницу с этим кодом правильно.

Она должна содержать:

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

Что конкретно означает HTTP / 1.1 302?

В какой-то статье, которую я однажды прочитал, говорилось, что это означает прыжок (с одного URI на другой), но я обнаружил этот «302», даже когда на самом деле никакого прыжка не было!

Редирект 302 означает, что страница была временно перемещена, а 301 означает, что она была перемещена навсегда.

Этот вопрос задавали давно, когда еще витал RFC 2616. Некоторые ответы на этот вопрос основаны на таком документе, который сегодня уже не актуален. Цитата Марка Ноттингема, который на момент написания статьи является сопредседателем рабочих групп IETF HTTP и QUIC:

Старый RFC 2616 был заменен следующими документами, которые вместе определяют протокол HTTP / 1.1:

Поэтому я стремлюсь дать ответ на основе RFC 7231, который является текущим справочником для кодов состояния HTTP / 1.1.

Код 302 состояния

Веб-браузеры могут измениться с POST на GET в последующем запросе. Если такое поведение нежелательно, 307 вместо него можно использовать код состояния (временное перенаправление).

Вот как 302 код состояния определяется в RFC 7231 :

Код состояния 302 (Найден) указывает, что целевой ресурс временно находится под другим URI. Поскольку перенаправление может иногда изменяться, клиент должен продолжать использовать действующий URI запроса для будущих запросов.

Серверу СЛЕДУЕТ генерировать Location поле заголовка в ответе, содержащее ссылку URI для другого URI. Пользовательский агент МОЖЕТ использовать Location значение поля для автоматического перенаправления. Полезные данные ответа сервера обычно содержат короткую гипертекстовую заметку с гиперссылкой на разные URI.

Примечание. По историческим причинам пользовательский агент МОЖЕТ изменить метод запроса с POST на GET для последующего запроса. Если такое поведение нежелательно, 307 вместо него можно использовать код состояния (временное перенаправление).

Веб-страница временно недоступна по непредвиденным причинам. Таким образом, поисковые системы не обновляют свои ссылки.

Другие коды состояния для перенаправления

В RFC 7231 определяет следующие коды состояния для переадресации:

Обратитесь к этому ответу для получения дополнительных сведений.

Как исправить код веб-ошибки Ошибка 302 Перемещено временно

В этой статье представлен номер ошибки Ошибка 302, широко известный как Перемещено временно, описанный как Веб-страница была временно перемещена, и доступен новый URL-адрес. Вы должны быть автоматически перенаправлены туда сервером.

Информация об ошибке

Имя ошибки: Перемещено временно
Номер ошибки: Ошибка 302
Применимо к: Windows 10, 8, 7, Vista, XP
Описание: Веб-страница была временно перемещена, и доступен новый URL-адрес. Вы должны быть автоматически перенаправлены туда сервером.

Это средство исправления может устранить такие распространенные компьютерные ошибки, как BSODs, замораживание системы и сбои. Он может заменить отсутствующие файлы операционной системы и библиотеки DLL, удалить вредоносное ПО и устранить вызванные им повреждения, а также оптимизировать ваш компьютер для максимальной производительности.

О кодах состояния

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

Чтобы объяснить проблему подробнее, вот несколько полезных сведений о кодах веб-ошибок, их симптомах, причинах и методах устранения.

Определения (Бета)

Здесь мы приводим некоторые определения слов, содержащихся в вашей ошибке, в попытке помочь вам понять вашу проблему. Эта работа продолжается, поэтому иногда мы можем неправильно определить слово, так что не стесняйтесь пропустить этот раздел!

Коды веб-ошибок также известны как коды состояния http. Существует пять различных классов кодов состояния http, и они всегда начинаются со следующих цифр, в зависимости от того, с какой ошибкой столкнулся пользователь. Это также симптомы ошибки, с которой столкнулся пользователь. Для дальнейшего объяснения ниже приведены коды состояния.

(Только для примера)

Коды 3XX возникают из-за определенных изменений, внесенных в исходный URI, и необходимости перенаправить пользователя на другой URI или некоторых других действий, описанных на странице ошибки.

Методы устранения

Для определенных кодов веб-ошибок существуют конкретные шаги по устранению неполадок. Однако существуют и обобщенные методы устранения, которые пользователи могут применять при возникновении подобных ошибок.

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

Сообщения HTTP

Сообщения HTTP состоят из текстовой информации в кодировке ASCII, записанной в несколько строк. В HTTP/1.1 и более ранних версиях они пересылались в качестве обычного текста. В HTTP/2 текстовое сообщение разделяется на фреймы, что позволяет выполнить оптимизацию и повысить производительность.

Механизм бинарного фрагментирования в HTTP/2 разработан так, чтобы не потребовалось вносить изменения в имеющиеся APIs и конфигурационные файлы: он вполне прозрачен для пользователя.

HTTP запросы и ответы имеют близкую структуру. Они состоят из:

Запросы HTTP

Стартовая строка

Заголовки

Заголовки запроса HTTP имеют стандартную для заголовка HTTP структуру: не зависящая от регистра строка, завершаемая ( ‘:’ ) и значение, структура которого определяется заголовком. Весь заголовок, включая значение, представляет собой одну строку, которая может быть довольно длинной.

Существует множество заголовков запроса. Их можно разделить на несколько групп:

Тела можно грубо разделить на две категории:

Ответы HTTP

Строка статуса (Status line)

Стартовая строка ответа HTTP, называемая строкой статуса, содержит следующую информацию:

Пример строки статуса: HTTP/1.1 404 Not Found.

Заголовки

Заголовки ответов HTTP имеют ту же структуру, что и все остальные заголовки: не зависящая от регистра строка, завершаемая двоеточием ( ‘:’ ) и значение, структура которого определяется типом заголовка. Весь заголовок, включая значение, представляет собой одну строку.

Существует множество заголовков ответов. Их можно разделить на несколько групп:

Тела можно разделить на три категории:

Фреймы HTTP/2

Сообщения HTTP/1.x имеют несколько недостатков в отношении производительности:

Фреймы HTTP сейчас прозрачны для веб-разработчиков. Это дополнительный шаг, который HTTP/2 делает по отношению к сообщениям HTTP/1.1 и лежащему в основе транспортному протоколу. Для реализации фреймов HTTP веб-разработчикам не требуется вносить изменения в имеющиеся APIs; если HTTP/2 доступен и на сервере, и на клиенте, он включается и используется.

Заключение

Сообщения HTTP играют ключевую роль в использовании HTTP; они имеют простую структуру и хорошо расширяемы. Механизм фреймов в HTTP/2 добавляет ещё один промежуточный уровень между синтаксисом HTTP/1.x и используемым им транспортным протоколом, не проводя фундаментальных изменений: создаётся надстройка над уже зарекомендовавшими себя методами.

HTTP Gallery

3. HTTP Status Codes and Errors

An HTTP request can fail because of a network error or because of problems encountered while the request is executing on the web server.

3.1 Network Errors

If a network error occurs while transmitting a request message, error information is available from the underlying network component; e.g. Windows Sockets or WinInet. Monitoring tools like HttpWatch can display error codes for situations such as:

3.2 Status Codes

HTTP status codes are returned by web servers to describe if and how a request was processed. The codes are grouped by the first digit:

Any code starting with ‘1’ is an intermediate response and indicates that the server has received the request but has not finished processing it. For example, IIS initially replies with 100 Continue when it receives a POST request and then with 200 OK once it has been processed (See 6. Methods)

These codes are used when a request has been successfully processed. For example, the value 200 is used when the requested resource is being returned to the HTTP client in the body of the response message.

Codes starting with a ‘3’ indicate that the request was processed, but the browser should get the resource from another location. Some examples are:

The requested resource has been temporarily moved and the browser should issue a request to the URL supplied in the Location response header. (See 7. Redirection)

The requested resource has not been modified and the browser should read from its local cache instead. The Content-Length header will be zero or absent because content is never returned with a 304 response (See 5. Caching for more detail)

The server returns these codes when they is a problem with the client’s request. Here are some examples:

Anonymous clients are not authorized to view the requested content and must provide authentication information in the WWW-Authenticate request header. (See 10. Authentication for more detail)

The requested resource does not exist on the server

A status code starting with the digit 5 indicates that an error occurred on the server while processing the request. For example:

An internal error occurred on the server. This may be because of an application error or configuration problem

The service is currently unavailable, perhaps because of essential maintenance or overloading

Example 3

Question: Can you work out why the following images are not displayed correctly?

» onclick=»this.style.visibility = ‘hidden’; ShowAnswers();»/>

The hostname used in the URL is missing a ‘w’ (i.e. ww rather than www) causing the error ERROR_INTERNET_NAME_NOT_RESOLVED to be returned by IE.

The URL for this image incorrectly uses port 81 and the error ERROR_INTERNET_CANNOT_CONNECT is returned by IE.

The TCP connection was closed before the server could return its response, causing IE to return the error ERROR_INTERNET_CONNECTION_RESET

The request was processed by the server but the server returned 404 Object Not Found because the image does not exist at the specified location.

No access to this image is allowed. The server returned 403 Forbidden

The server returned 501 Internet Server Error

Using HttpWatch with Example 3

To view the errors that occur when downloading the images:

Cтатус HTTP ответа веб сервера

Код состояния HTTP — это часть строки заголовка, ответа веб сервера на запрос клиента, информирующая о результате запроса и о том, что клиент должен предпринять далее

Код состояния HTTP — это часть строки заголовка, ответа веб сервера на запрос клиента, информирующая о результате запроса и о том, что клиент должен предпринять далее. Думаю не все знают как выглядит заголовок ответа сервера, зато уверен, каждый, пользующийся интернетом, не раз сталкивались, со страницей 404 Not Found или 403 Forbadden. Это и есть, видимый пользователю результат, выдачи сервером, того или иного кода статуса в строке заголовке.

Коды состояния HTTP, разделены на 5 категорий. Клиент может быть не знаком с тем или иным кодом ответа HTTP, однако он должен отреагировать согласно категории кода. Итак протокол HTTP поддерживает следующие коды статуса, разделенные по категориям:

1xx: Information — информационные

2xx: Success — Успешное завершение

3xx: Redirection — Редирект ( перенаправление )

Коды данной категории, сообщают клиенту, что для завершения запроса, ему необходимо выполнить дополнительный запрос, как правило по другому URI, соответствующий адрес указывается в строке Location, ответа сервера. Программа — клиент может совершать дополнительные запросы без участия пользователя, при условии что дополнительный запрос делается методами GET или HEAD.

Некоторые клиенты некорректно работают с редиректами 301 и 302, применяя в запросе ко второму ресурсу метод GET, несмотря на то, что первый запрос был сделан с использованием другого метода. В протоколеHTTP версии 1.1, вместо ответа статуса 302, были введены дополнительные коды ответов, 303 и 307. Изменять метод, необходимо только в случает ответа сервера со статусом 303, в остальных случаях использовать исходный метод.

300 Multiple Choices — Несколько вариантов выбора. По запрошенному URI, существует несколько вариантов ресурса, различных по MIME типу. языку или другим признакам. В ответе сервера, передается список альтернатив, выбираемый клиентским приложением автоматически или самим пользователем. Появился в протоколе версии HTTP/1.0. 301 Moved Permanently — Перемещёно окончательно. Запрошенный ресурс был окончательно перемещен на URI, указанный в строке заголовка Location, ответа сервера. Некоторые клиенты, при обработке данного кода, ведут себя некорректно, см. выше. Появился в протоколе версии HTTP/1.0. 302 Found — Найдено ( Moved Temporarily ) Данный код статуса сообщает клиенту, что ресурс временно доступен по другому URI, указанному в строке заголовка Location, заголовка ответа сервера. Данный код используется например, при согласовании содержимого ( Content Negotiation ), выполняемого сервером. Появился в протоколе версии HTTP/1.0. 303 See Other — Смотреть другое. Документ из запрошенного URI, нужно запросить по адресу, указанному в строке заголовка Location, заголовка ответа сервера, используя метод GET, невзирая на то, каким методом был сделан первый запрос. Появился в протоколе версии HTTP/1.1. 304 Not Modified — Не изменялось. Данный код выдается в случае запроса документа, методом GET, с использованием заголовков If-Modified-Since или If-None-Match, и документ не был изменен с указанного момента времени. Появился в протоколе версии HTTP/1.0. 305 Use Proxy — Использовать прокси сервер. Запрос к ресурсу, должен выполняться через прокси-сервер., адрес которого, указан в строке заголовка Location, заголовка ответа сервера. Появился в протоколе версии HTTP/1.1. 307 Temporary Redirect — Временное перенаправление Запрошенный ресурс временно доступен по URI, указанному в строке заголовка Location, заголовка ответа сервера. Появился в протоколе версии HTTP/1.1.

4xx: Client Error — Ошибка клиента

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

400 Bad Request — Плохой запрос. Из-за синтаксической ошибки, запрос не был понят сервером. Появился в протоколе версии HTTP/1.0. 401 Unauthorized — Не авторизован. Ресурс требует идентификации пользователя. Клиентское приложение запрашивает у пользователя данные для аутентификации ( имя, пароль ) и передает их на сервер в заголовке WWW-Authenticate. Если данные указаны не правильно, будет снова выдан этот-же код статуса. Появился в протоколе версии HTTP/1.0. 402 Payment Required — Необходима оплата. Пока не используется. Появился в протоколе версии HTTP/1.1. 403 Forbidden — Запрещено. Сервер отказал в доступе к запрошенному ресурсу ввиду ограничений. Ограничения могут быть любыми, установленными администратором сервера, или определенным веб приложением. Например, в целях безопасности, закрыт доступ к файлу, .htacces или .htpasswd или к закрытой директории сайта, или в случае, когда аутентификация должна производится через веб приложение ( например сайтовый движок ), ну или блокировка по IP адресу, в случае слишком частых обращений. Появился в протоколе версии HTTP/1.0. 404 Not Found — Не найдено. Сервер не нашел запрошенный ресурс по указанному адресу. Кроме того данный код ответа можно использовать вместо 403, с целью, скрыть расположение документа, доступ к которому запрещен. Появился в протоколе версии HTTP/1.0. 405 Method Not Allowed — Метод не поддерживается. Клиент попытался использовать метод, недопустимый для данного ресурса. Сервер передает в заголовке, строку Allow, содержащую список допустимых методов. Появился в протоколе версии HTTP/1.1. 406 Not Acceptable — Не приемлемо. Запрошенный ресурс, не удовлетворяет, запрошенные характеристики. В случае, если запрос был сделан не методом HEAD, сервер вернет список допустимых характеристик запрошенного ресурса. Появился в протоколе версии HTTP/1.1. 407 Proxy Authentication Required — Необходима прокси авторизация. Данный код статуса, аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Появился в протоколе версии HTTP/1.1. 408 Request Timeout — Время ожидания истекло. Истек таймаут ожидания передачи данных, между сервером и клиентом. Появился в протоколе версии HTTP/1.1. 409 Conflict — Конфликт. Конфликтная ситуация при обращении к ресурсу. Такое может произойти, например, при попытке одновременного изменения файла, методом PUT, несколькими клиентами. Появился в протоколе версииHTTP/1.1. 410 Gone — Удалён. Данный ответ выдается в случае, если документ был по указанному URI, но в данный момент удален. Появился в протоколе версии HTTP/1.1. 411 Length Required — Необходима длина. Этот код статуса говорит о том, что для данного URI, в заголовке запроса, должно быть указано значение в поле 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 слишком длинный. Слишком длинная строка запроса. Такая ситуация может произойти, например в случае попытки, передать данные методом GET, вместо использования POST. Появился в протоколе версии HTTP/1.1. 415 Unsupported Media Type — Неподдерживаемый тип данных. Сервер, по какой-то причине, отказался обрабатывать запрошенные данные, используемым методом. Появился в протоколе версии HTTP/1.1. 416 Requested Range Not Satisfiable — Запрашиваемый диапазон не достижим. В строке заголовка запроса Range, установлен диапазон, выходящий за рамки запрошенного ресурса и отсутствует строка If-Range. Появился в протоколе версии HTTP/1.1. 417 Expectation Failed — Ожидаемое не приемлемо. Сервер не может обработать строку заголовка запроса Expect. Появился в протоколе версии HTTP/1.1. 422 Unprocessable Entity — Необрабатываемый экземпляр. Запрос принят, тип данных может быть обработан, синтаксис XML данных в теле запроса верен, но имеет место логическая ошибка, не позволяющая обработать запрос к ресурсу. Используется в протоколеWebDAV. 423 Locked — Заблокировано. Запрошенный ресурс заблокирован от данного метода. Используется в протоколе WebDAV. 424 Failed Dependency — Невыполненная зависимость. Выполнение запроса, может зависеть от результата выполнения, какой-либо другой операции, при невыполнении данного условия, будет выдан этот код статуса. Используется в протоколе WebDAV. 425 Unordered Collection — Беспорядочный набор. Этот код статуса будет выдан в случае, если клиент отправил запрос обозначив положение в неотсортированной коллекции или используя порядок следования элементов отличный от серверного. Введено в черновике по WebDAV Advanced Collections Protocol. 426 Upgrade Required — Требуется обновление. Указание сервера, клиенту, обновить протокол. Заголовок ответа, должен содержать правильно составленные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредствомHTTP. 449 Retry With — Повторить с… Выдается в случае поступления не достаточного количества информации для обработки запроса. В заголовок ответа сервера, помещается строка Ms-Echo-Request. Введено корпорацией Microsoft дляWebDAV.

5xx: Server Error — Ошибка на стороне сервера

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

500 Internal Server Error — Внутренняя ошибка сервера. Любая внутренняя ошибка на стороне сервера не подпадающая под остальные ошибки из категории 5хх. Появился в протоколе версии HTTP/1.0. 501 Not Implemented — Не реализовано. Сервер не поддерживает, необходимых для обработки запроса, возможностей. ( например не поддерживается необходимый метод обработки ). Появился в протоколе версии HTTP/1.0. 502 Bad Gateway — Плохой шлюз. Сервер, работающий в качестве прокси или шлюза, получил сообщение о неудачное в промежуточной операции. Появился в протоколе версии HTTP/1.0. 503 Service Unavailable — Сервис недоступен. Сервер не в состоянии обрабатывать запросы клиентов по техническим причинам. Появился в протоколе версии HTTP/1.0. 504 Gateway Timeout — Истек таймаут ожидания ответа шлюза. Проксирующий сервер или шлюз, не дождался ответа от вышестоящего сервера для завершения обработки запроса. Появился в протоколе версии HTTP/1.0. 505 HTTP Version Not Supported — Версия HTTP протокола не поддерживается. Сервер не поддерживает, или не может обработать, указанную в заголовке версию HTTP протокола. Появился в протоколе версии HTTP/1.0. 506 Variant Also Negotiates — Вариант тоже согласован. Из-за не верной конфигурации, выбранный вариант указывает сам на себя, в следствии чего, связывание прерывается. Добавлено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation. 507 Insufficient Storage — Переполнение хранилища. Недостаточно места для обработки текущего запроса. Возможно временная проблема. Используется в протоколе WebDAV. 509 Bandwidth Limit Exceeded — Пропускная возможность канала исчерпана. Данный код статуса, используется в случае превышения веб площадкой, отведенного ей лимита, на потребляемый трафик. Данный код не описан ни одним RFC и используется только модулем bw/limited, панели веб-хостинга cPanel. 510 Not Extended — Нет расширения. У сервера отсутствует расширение, которое пытается использовать клиентом. Сервер может передавать информацию, об имеющихся у него расширениях. Введено в RFC 2774 для дополнения протокола HTTPподдержкой расширений.

Методы обработки запросов HTTP

HTTP метод — это основная операция, которую необходимо выполнить над ресурсом. В названии могут использоваться любые символы, кроме управляющих последовательностей и разделителей, как правило это короткое слово на английском языке. Имена методов HTTP зависимы от регистра.

Любой веб сервер обязан работать, по крайней мере с двумя методами GET и HEAD. Если сервер не смог определить метод, указанный в заголовке запроса клиента, он должен вернуть код статуса 501 (Not Implemented), если-же метод серверу известен, но неприменим к данному ресурсу, будет возвращен код статуса 405 (Method Not Allowed). Как в первом, так и во втором случае, сервер должен включить в свой ответ, заголовок Allow со списком методов, которые он поддерживает.

Метод OPTIONS

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

Что-бы выяснить возможности сервера, клиент должен указать в запросе URI, символ — «*«, то есть данный запрос к серверу выглядит как: OPTIONS * HTTP/1.1. Кроме прочего, данный запрос может быть использован для проверки работоспособности сервера и поддержки им протокола HTTP, версии 1.1. Результаты данного запроса не кэшируются.

Метод GET

Метод GET, применяется для запроса конкретного ресурса. Так-же с помощью GET, может быть инициирован некий процесс, при этом, в тело ответа, включается информация о ходе выполнения инициированного запросом действия.

Параметры для выполнения запроса, передаются в URI запрашиваемого ресурса, после символа «?«. Запрос в таком случае выглядит примерно так: GET /some/resource?param1=val1&param2=val2 HTTP/1.1.

Как установлено в стандарте HTTP, запросы методом GET, являются идемпотентными, то есть, повторная отправка одного и того-же запроса, методом GET, должна приводить к одному и тому-же результату, в случае, если сам ресурс, в промежутках между запросами, изменен не был, что позволяет кэшировать результаты, выдаваемые на запрос методом GET.

Кроме вышесказанного, существуют еще два вида метода GET, это:
условный GET, содержащий заголовки If-Modified-Since, If-Match, If-Range и им подобные,
Частичный GET, содержащий заголовок Range с указанием байтового диапазона данных, которые сервер должен отдать. Данный вид запроса используется для докачки и организации многопоточных закачек.

Порядок работы с этими подвидами запроса GET, стандартами определен отдельно.

Метод HEAD

Данный метод, аналогичен методу GET, с той лишь разницей, что сервер не отправляет тело ответа. Метод HEAD, как правило используется для получения метаданных ресурса, проверки URL ( есть-ли указанный ресурс на самом деле ) и для выяснения факта изменения ресурса с момента последнего обращения к нему.

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

Метод POST

Метод POST, используется для передачи пользовательских данных на сервер, указанному ресурсу. Примером может послужить HTML форма с указанным атрибутом Method=»POST», для отправки комментария к статье. После заполнения необходимых полей формы, пользователь жмет кнопку «Отправить» и данные, методом POST, передаются серверному сценарию, который в свою очередь выводит их на странице комментариев. Таким-же образом, с помощью метода POST, можно передавать файлы.

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

Если в результате запроса методом POST, возвращается код 200 (Ok) или 204 (No Content), в тело ответа сервера, добавляется сообщение о результате выполнения запроса. Например, если был создан ресурс, сервер вернет 201 (Created), указав при этом URI созданного ресурса в заголовке Location.

Ответы сервера, на выполнение метода POST, не кэшируются.

Метод PUT

Используется для загрузки данных запроса на указанный URI. В случае отсутствия ресурса по указанному в заголовке URI, сервер создает его и возвращает код статуса 201 (Created), если ресурс присутствовал и был изменен в результате запроса PUT, выдается код статуса 200 (Ok) или 204 (No Content). Если какой-то из переданных серверу заголовков Content-*, не опознан или не может быть использован в данной ситуации, сервер возвращает статус ошибки 501 (Not Implemented).

Главное различие методов PUT и POST в том, что при методе POST, предполагается, что по указанному URI, будет производиться обработка, передаваемых клиентом данных, а при методе PUT, клиент подразумевает, что загружаемые данные уже соответствуют ресурсу, расположенному по данному URI.

Ответы сервера при методе PUT не кэшируются.

Метод PATCH

Работает аналогично методу PUT, но применяется только к определенному фрагменту ресурса.

Метод DELETE

Удаляет ресурс, расположенный по заданному URI.

Метод TRACE

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

Метод LINK

Связывает указанный ресурс с другим ресурсом.

Коды ответа сервера и коды ошибок

Если вы собираетесь заниматься web-технологиями, созданием и содержанием сайтов или их раскруткой, нужно научиться общаться с ними.

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

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

В связи с этим администратор должен реагировать мгновенно и понимать, на что именно жалуется или о чем сообщает его сервис (знать все коды ответа и ошибки сервера), чтобы не терять клиентов.

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

Основные ошибки – коды и их значения

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

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

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

По назначению ответы делятся на пять категорий и распределяются сотнями 100-500. Различают следующие 5 типов кодов:

Большинство ошибок имеют информационных характер независимо от принадлежности к категории. Однако именно это и помогает выявить нарушение в работе между клиентом и сервером, а также быстро сориентироваться в связующих между ними.

Сообщения информационного характера: 1ХХ

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

Продолжение действия (Continue server code): 100

Как ни странно, это не ошибка и не неполадка. Видеть это сообщение в коде – удовольствие для системного администратора.

100 Continue означает стабильную работу в штатном режиме. То есть сбоев в обработке информации по запросу не было, и все они обрабатывались сервером при обращении клиента.

Сообщением 100 сервис говорит о запуске и продолжении обработки данных по запросу, пока все пакеты не будут переданы.

Оно используется как начало соединения. И так будет до окончания обработки и завершения сессии.

Протоколы переключений (Switching Protocols): 101

Это еще одно сообщение, которое имеет только информационный характер. Такое можно обнаружить в логах любого сервера или базы данных, к которой обращается сетевой ресурс.

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

Очень часто можно увидеть подобные сообщения в записях, когда пользователь использует очень старый браузер, который не умеет работать с современными версиями HTML, или же при обращении к сервису по защищенному протоколу, когда таковой не является принятым по умолчанию, но поддерживается для ответа, например, https:// вместо http:// или наоборот.

Сообщения подтверждения и принятия (Success): 2ХХ

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

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

Все хорошо (ОК): 200

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

200 ОК – наиболее популярный и известный код любого лога. Он крайне незаметен, поскольку если все хорошо, то и обращать внимание незачем.

Изначально подобный способ ведения системных записей использовался операционными системами *.NIX, которые при загрузке общались с администратором приблизительно также, выдавая код «ОК» или «Fail» для каждой ожидающей загрузки службы.

Создано (Created): 201

Код используется по назначению, указанному в названии. Как правило, подобное сообщение означает создание чего-то нового в процессе или по завершении его обработки и запроса.

Хорошим примером будет создание нового профиля пользователя по окончании регистрации. В таком случае будет несколько записей 201 Created при создании имени пользователя, пароля, профиля, пользовательской страницы.

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

Принято (Accepted): 202

Этот код означает, что запрос принят и находится в процессе или ожидании обработки сервером, например, когда нагрузка на ресурс очень велика.

В этом состоянии сессия может обрываться при невыполнении определенного условия или будет принята и выполнена позже.

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

Неактуальные данные (Non-Authoritative): 203

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

Сообщение Non-Authoritative 203 часто используется вместо 200, когда запрос ведет к информации, находящейся в архивах (для сокращения объема и увеличения обработки скорости запроса) или в резервных базах.

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

Нет содержимого (No Content): 204

Таким образом, сервер сообщает, что от клиента были получены данные запроса, он понял информацию и обработал её.

Но согласно полученным данным, ему нечем ответить, поскольку нет содержимого, которое соответствует полученному запросу. То есть данных для этого пользователя не существует.

Используется код состояния HTTP 204 No Content в основном для того, чтобы не запрещать обработку сессий скриптов, при этом документ может оставаться неизменным.

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

Сбросить содержимое (Reset Content): 205

По смыслу запись 205 Reset Content аналогична предыдущей. Однако в этом состоянии сервер требует от клиента обновления страницы.

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

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

Частичный сброс содержимого (Partial Reset): 206

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

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

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

Многозадачный статус (Multi-Status): 207

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

Redirect и опции перенаправления: 3ХХ

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

Как правило, запрос клиента состоит не только из текстовой информации, по которой он ищет контент, но и из ссылки реферера, которая указывает откуда и с какими параметрами посетитель перешел на сайт.

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

Это помогает настроить функцию перенаправления таким способом, чтобы максимально увеличить отдачу, предоставляя клиенту как можно более релевантные страницы и экономя на их раскрутке.

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

Но можете и направить его на страницы доставки вашего сервиса или партнера – опять же не потеряете посетителя просто так.

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

Один из многих (Multiple Choices): 300

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

Такой вид запроса используется в том случае, когда релевантная ссылка ведет не на соответствующий контент, а на каталог, в котором он находится.

То есть указанный путь не до конца прописан пользователем или специально так обработан сервером.

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

Перемещена на постоянной основе (Moved Permanently): 301

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

Есть еще одно применение, которое интересует администраторов рекламных площадок. Это специально размещенные страницы сайта с подробным описанием какого-либо товара, но ссылка специально указана неверно.

Поэтому сервер выводит сообщение 301 и перенаправляет на товар без описания (используется для экономии места теми, кто продвигает продажи товаров текстами копирайтеров).

Подробно про 301 редирект прочитаете из предыдущей стати «Как настроить на сайте 301 редирект».

Страница обнаружена (Found): 302

Код означает временное перемещение ресурса. Он часто используется для тестирования сторонних хостингов или серверов на предмет устойчивости при большом количестве запросов или dDOS атаке.

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

Увидеть другую (See Other): 303

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

То есть пользователь попал не на ту страницу, которая ему на самом деле нужна, и код указывает ему, по отношению к какому адресу правильнее сформировать запрос.

Как правило, эту опцию используют тогда, когда нужно перенаправить данные исполняемого скрипта в процессе сессии на выбранный сайт для POST обработки.

Не подвергался изменениям (Not Modified): 304

Код состояния HTTP 304 Not Modified означает, что исполнение запроса пользователя на этой странице интересует только в том случае, если произошли какие-либо изменения. Иначе используется старая версия из кэша.

При этом обращения к серверу от клиента не происходит вообще, а если сессия активируется, то будет перенаправлена.

Опция очень удобна, поскольку, используя один из параметров внесения изменений, посетитель может отслеживать и наблюдать за новостями ресурса со стороны клиента. Со стороны сервера это позволяет заинтересованного пользователя перекидывать на измененные документы при необходимости (по запросу об изменениях).

Доступ к странице при помощи прокси (Use Proxy): 305

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

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

Включите прокси (Switch Proxy): 306

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

Однако на данный момент опция не используется за ненадобностью.

Временное перемещение (Temporary Redirect): 307

Используется при необходимости временного замещения одной страницы на другую и перенаправления на неё пользователя. Однако код 307 немного отличается по функциональности от 302.

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

Ошибки со стороны клиента: 4ХХ

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

Неверный запрос (Bad Request): 400

Код применяется, когда клиент неверно задал запрос, к примеру, допустил синтаксическую ошибку, а сервер не в состоянии её обработать.

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

Не авторизирован (Unauthorized): 401

Часто используется на сервисах, предоставляющих платный доступ, или форумах, просмотр некоторых тем которых доступен только для авторизированных пользователей.

При этом посетитель будет получать сообщение 401 Unauthorized с предложением пройти регистрацию.

Также код может быть использован при неверном или частичном прохождении процесса идентификации или регистрации.

Например, когда сервер разрешает доступ с логином и паролем, но пока они не подтверждены администратором, не пускает на некоторые страницы сайта.

Необходима оплата (Payment Required): 402

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

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

Всемирно известное хранилище видео данных YouTube использует код 402, когда активность пользовательских запросов вызывает подозрение.

В этом случае, вызывается опция, активирующая скрипт введения каптчи (CAPTHA).

Запрещен (Forbidden): 403

Код применяется при принятии и обработке процесса для ответа пользователю отказом, в праве на просмотр страницы.

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

Не найден (Not Found): 404

Такая проблема широко распространена. Она несет в себе информацию о прекращении существования страницы.

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

Как создать на сайте 404 страницу и перенаправлять не нее посетителей читайте в этой статье.

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

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

Способ не приемлем (Method Not Allowed): 405

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

Так как исполнение невозможно, то сервер сообщает об этом при помощи кода 405.

Не допустимый (Not Acceptable): 406

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

Клиентская программа-обозреватель не дает принимать информацию от сервера, но при этом передает запрос на отображение.

Неверная аутентификация на прокси-сервере (Proxy Authentication Required): 407

Код немного подобен 401, однако тут речь идет не о правильности сервера и его использовании, а именно об авторизации на прокси посредством логина и пароля.

Сообщение работает, когда невозможно передать данные из-за неверных параметров прокси-сервера.

Время ожидания запроса истекло (Request Timeout): 408

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

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

Проблема с обращением к серверу (Conflict): 409

Сообщение выдается сервером при попытке замены более новой копии файла или архива на более старую или неактуальную.

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

Запрос уже ушел (Gone): 410

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

Длина запроса (Length Required): 411

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

Условие нарушено (Precondition Failed): 412

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

Сервер может сообщать, что такой запрос не подходит именно этому ответу.

Длина запроса слишком велика (Request Entity Too Large): 413

Используется при понятном серверу требовании, однако в параметрах указано ограничение на обрабатываемую информацию.

Следует уменьшить размер фразы для поиска нужного контента.

Длина ссылки запроса слишком велика (Request-URL Too Long): 414

Необходим при использовании слишком длинных ссылок при преобразовании и формировании сложных запросов.

Если сервер не способен их обработать, он выдает сообщение 414.

Неподдерживаемый формат (Unsupported Media-Type): 415

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

Например, когда открытие jpg картинки доступно только для администратора или зарегистрированного посетителя.

Недоступность диапазона (Requested Range Not Satisfiable): 416

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

Если добавлены лишние строки, размер будет изменен, и ошибка 416 сообщит администратору об этом.

Ожидание прервано (Expectation Failed): 417

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

Процесс не сможет запуститься и может остаться как зависшая в ожидании сессия, поскольку неверно заполнено поле Expect.

Я чайник (I’m a teapot): 418

17 лет назад это сообщение было разработано ради смеха и использовалось как шутка в день смеха 1 апреля. Современные http обработчики не воспринимают его.

Невероятный объект (Unprocessable Entity): 422

Сервер таким образом сообщает, что он принял запрос, прочитал и понял его, но какая-то ошибка мешает правильно его обработать.

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

Заперто (Locked): 423

Метод, которым вы обращаетесь к серверу клиентским запросом, запрещен и системным администратором.

Как правило, такой вид блокировок употребляется для того, чтобы посетитель прошел регистрацию и верификацию на сервере.

Плохая зависимость (Failed Dependency): 424

Запрос от посетителя был прерван из-за невыполнения других условий для совершения действия.

Может использоваться при отказе от подтверждения действия, например, при отрицательном ответе на вопрос: есть ли вам «18», процесс регистрации не сможет быть завершен и сервер сообщит об этом.

Неупорядоченный каталог (Unordered Collection): 425

Используется при попытке доступа к данным, которые были переведены в статус «черновик», то есть находящимся в процессе редактирования или внесения изменений.

Ссылка в это время остается целой, однако пользовательский интерфейс отключен.

Обязательное обновление запроса (Upgrade Required): 426

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

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

Условия предварительного воздействия (Precondition Required): 428

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

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

В результате серверу непонятно, какой из ответов возвращать, поэтому происходит конфликт.

Слишком много обращений (Too Many Requests): 429

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

Также код необходим для сообщений о попытке взлома сервера методом dDOS (множественные запросы или крупные пакеты, забивающие трафик к серверу или нагружающие его процессорную мощность) или брутфорсом (подбор паролей, приемлем при взломах почтового ящика).

Заголовок поля очень длинный (Request Header Fields Too Large): 431

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

Нет ответа (No Response): 444

Применяется как сообщение о том, что посетителю на запрос было отказано в получении ответа.

В этом случае сервер отказался от обработки, подозревая, что запрос вызван вирусным ПО или хакерской атакой.

Готов после… Retry With (Microsoft): 449

Код взят в употребление компанией Майкрософт как ответ пользователю на неверный запрос или его части.

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

Заблокировано при помощи родительского контроля (Blocked by Windows Parental Controls (Microsoft)): 450

Используется как сообщение от ресурсов, которые были заблокированы на персональных компьютерах при помощи программного обеспечения.

Чаще всего необходим для сообщения о том, что запрос выходит за рамки разрешенные параметрами родительского контроля, осуществляемым при помощи штатных средств Microsoft Windows.

Недоступно по причинам нелегальности (Unavailable For Legal Reasons): 451

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

Часто используется уже после блокировки правительством или такими органами, как Росскомнадзор.

Ошибки со стороны сервера: 5ХХ

Коды состояния HTTP 5й серии призваны указывать на проблемы со стороны обработки сервером. Они используются в то время, когда запрос, отправленный пользователем, правильно сформирован и не содержит лишних и неверных данных.

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

Ошибка внутри сервера (Internal Server Error): 500

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

Вероятнее всего произошло обращение по несуществующей ссылке или запрос на объект, которого никогда не было.

Функция не реализована (Not Implemented): 501

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

Неверный шлюз (Bad Gateway): 502

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

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

Сервер недоступен (Server Unavailable): 503

Сервер может отказать посетителю в обработке запроса или процесса по нескольким причинам.

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

Время ожидания шлюза истекло (Gateway Timeout): 504

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

Чаще всего встречается в случаях, когда сервер сам является шлюзом или подключается к нему для передачи информационных данных.

Версия протокола не может быть использована (HTTP Version Not Supported): 505

Необходима в тех случаях, когда в программе-обозревателе не соответствует версия HTTP указанная сервером. Проблема возникает либо при использовании очень старых браузеров или неправильно заданных запросов.

Как вариант – доступ предоставляется через защищенный протокол HTTPS, а клиент задает HTTP вручную или переходит по такой ссылке и наоборот.

Вариант не устраивает (Variant Also Negotiates): 506

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

Для хранения недостаточно места (Insufficient Storage): 507

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

Лимит пропускной способности исчерпан (Bandwidth Limit Exceeded): 509

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

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

Запрещен к распространению (Not Extended): 510

Если серверу не предоставлено достаточно данных о клиенте, он отказывает ему как неизвестному или неопознанному посетителю в предоставлении информации.

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

Авторизация в сети не пройдена (Network Authentication Required): 511

Код популярен и часто используется в общедоступных сетях. Может выдаваться по окончании выделенного клиенту времени (часто применяется в кафе и фастфудах).

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

Заключение

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

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

The Difference Between 200, 301, 302, 304, 404 Status Codes

HTTP is a widespread data transfer protocol, initially intended for the transfer of documents that contain links, allowing you to organize the transition to other documents.

The primary task of the HTTP protocol is the exchange of data between a user application accessing web resources (usually a web browser) and a web server. The World Wide Web operates thanks to the HTTP protocol. When a search engine or visitor requests a web server, a three-character HTTP code is returned to it, indicating what is happening. Here’s what they may mean:

How to Manage HTTP Status of Short Links

Today, on the Short.io blog, we’ll figure out the difference between the most spread HTTP codes: 200, 301, 302, 304, 404.

200 OK

200 Code informs about successful processing of the request. For example, the client requested data. The 200 response means that this data is displayed successfully. The search engine indexes resources and links that provide the 200 code. For the search robots, the 200 response means that the page really exists, so it can be included to the index base. If you want the search engine to index the pages, make sure they have the 200 response.

301 Moved Permanently

Updating your website or a domain, remember to use a 301 redirect. The 301 redirect is an instruction that indicates that the page has been moved. When clicking a link, we expect to find a page on a given address, but it has changed. No problem, the web server redirects to a new address. Changes won’t be noticeable for users if they’re not paying attention to the updated URL in the address bar.

It’s the best method for maintaining the search positions and the results of promotion when moving the website to a new address.

302 Found (Moved Temporarily)

If this type of redirection is created on the site, it means that the page is temporarily moved to another address. The disadvantage is that it does not transmit the weight of the page. As a result, the site loses the external link juice and the web-page weight.

302 redirect is required in the following cases:

304 Not Modified

The HTTP error code 304 means that there is a problem with the URL you are trying to access. This problem could be caused in the following cases:

404 Not Found

The response reports that the server cannot find data according to the request. The most common causes of the error are:

404 errors can also appear due to the incorrect operation of the server, which can generate an error even when the resource is running.

How to check the response codes

You can use one of the programs on the Internet. Some do mass checks for all pages of the site, and some require you to enter a URL. Choose a service based on your tasks. The example is the HTTP Status service.

HTTP error code: 302 when calling https webservice

I am trying to call a SOAP RPC style web service and getting the following error:

Exception in thread «main» com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP status code 302:

This is a https web service and I have imported the certificate into cacerts thru browser but getting same result. Please note that, I can consume a REST webservice from the same machine without importing the certificate.

What I am missing when calling a SOAP service? Is it my client issue or something need to be done on the server side. I have access to the server.

3 Answers 3

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

HTTP status code 302 is a redirect, and so is unlikely due to a certificate problem. My initial guess is that you need to add a / (or remove it) from your URL. Some http server frameworks will redirect when a resource does not end in a /, so, instead of:

The other possibility is that this resource requires authentication and the server is redirecting you to a login page. If you want to know what is going on (and not guess), take a look a the the response headers for the 302. There will be a Location header telling you where the server wants you to go instead.

10 Описания кодов состояния (Status Code Definitions).

Каждый код состояния, описанный ниже, включает описание метода (или методов), за которым он может следовать и метаинформации, требуемой в ответе.

Этот класс кодов состояния указывает предварительный (временный) ответ, состоящий только из строки состояния (Status-Line) и опциональных заголовков, и завершающийся пустой строкой. Так как HTTP/1.0 не определял никаких 1xx кодов состояния, серверы НЕ ДОЛЖНЫ посылать 1xx ответы HTTP/1.0 клиентам, за исключением экспериментальных условий.

10.1.1 100 Продолжать, Continue.

Клиент может продолжать запрос. Этот промежуточный ответ используется, для того, чтобы сообщить клиенту, что начальная часть запроса была получена и еще не отвергнута сервером. Клиенту СЛЕДУЕТ продолжить посылку оставшихся данных запроса или, если запрос уже был выполнен, игнорировать этот ответ. Сервер ДОЛЖЕН послать заключительный ответ после того, как запрос будет выполнен.

10.1.2 101 Переключение протоколов, Switching Protocols.

Сервер понимает и желает выполнить запрос клиента, если протокол прикладной программы в этом соединении будет изменен на тот, который указан в поле заголовка сообщения Upgrade (раздел 14.41). Сервер переключит протокол на тот, который определен в поле заголовка ответа Upgrade непосредственно после пустой строки, которая завершает ответ с кодом состояния 101.

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

Этот класс кодов состояния указывает, что запрос клиента был успешно получен, понят, и принят.

10.2.1 200 OK.

Запрос был удачно выполнен. Информация, возвращаемая с ответом зависит от метода, используемого в запросе. Например: GET в ответе представлен объект, соответствующий запрошенному ресурсу; HEAD в ответе представлены поля заголовка объекта (entity-header), соответствующие запрошенному ресурсу. Тело сообщения (message-body) отсутствует; POST в ответе представлено описание объекта или содержится результат действия; TRACE в ответе представлен объект, содержащий сообщение запроса, полученого конечным сервером.

10.2.2 201 Создан, Created.

Запрос был выполнен и в результате был создан новый ресурс. Новый созданный ресурс может быть вызван по URI (одному или нескольким), возвращенным в объекте ответа; наиболее специфический URL для ресурса отдается в поле заголовка Location. Первоначальный сервер ДОЛЖЕН создать ресурс перед возвратом кода состояния 201. Если действие не может быть выполнено немедленно, сервер должен возвратить ответ с кодом состояния 202 (Принято, Accepted) вместо 201.

10.2.3 202 Принято, Accepted.

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

Ответ с кодом состояния 202 преднамеренно уклончив. Цель его состоит в том, чтобы позволить серверу принять запрос для некоторого другого процесса (возможно пакетно-ориентированного процесса, который выполняется только один раз в день) и не требовать при этом, чтобы соединение агента пользователя с сервером сохранялось до завершения процесса. Объекту, возвращенному с этим ответом СЛЕДУЕТ содержать индикатор текущего состояния запроса и либо ссылку на монитор состояния, либо некоторую оценку времени, когда пользователь может ожидать завершения выполнения запроса.

10.2.4 203 Не авторская информация, Non-Authoritative Information.

10.2.5 204 Нет содержимого, No Content.

Ответ с кодом состояния 204 НЕ ДОЛЖЕН содержать тела сообщения, и, таким образом, всегда завершается первой пустой строкой после полей заголовка.

10.2.6 205 Сбросить содержимое, Reset Content.

Сервер выполнил запрос, и агенту пользователя СЛЕДУЕТ отменить просмотр документа, который инициировал запрос. Этот ответ предназначен прежде всего для того, чтобы позволить ввод данных, осуществляемый пользователем, с последующей очисткой формы, в которой сделан ввод, так, чтобы пользователь мог легко инициировать следующее действие ввода. Ответ НЕ ДОЛЖЕН содержать объект.

10.2.7 206 Частичное содержимое, Partial Content.

Сервер выполнил частичный GET запрос ресурса. Запрос должен содержать поле заголовка Range (раздел 14.36), указывающее желаемый диапазон. Ответ ДОЛЖЕН содержать либо поле заголовка Content-Range (раздел 14.17), указывающее диапазон, включенный в ответ, либо тип содержимого (Content-Type) должен быть равным «multipart/byteranges», а поля Content-Range должны содержаться в каждой части. Если «multipart/byteranges» не используется, поле заголовка Content-Length в ответе ДОЛЖНО соответствовать фактическому числу октетов (OCTETs), переданных в теле сообщения (message-body).

Кэш, который не поддерживает заголовки Range и Content-Range НЕ ДОЛЖЕН кэшировать ответы с кодом состояния 206.

Этот класс кодов состояния указывает, что для выполнения запроса агенту пользователя необходимо придпринять дополнительное действие. Требуемое действие МОЖЕТ быть выполнено агентом пользователя без взаимодействия с пользователем, тогда и только тогда, когда во втором запросе используется метод GET или HEAD. Агенту пользователя НЕ СЛЕДУЕТ автоматически перенаправлять запрос более 5 раз, так как такие переадресации обычно указывают бесконечный цикл.

10.3.1 300 Множественный выбор, Multiple Choices.

Запрошенный ресурс имеет несколько представлений, и можно использовать любое из перечисленных. Каждое представление имеет свое расположение и информацию для агента по управлению диалогом (раздел 12), представленную таким образом, что пользователь (или агент пользователя) может выбрать наиболее подходящее представление и перенаправить запрос к нему.

Если запрос был отличен от HEAD, то ответу СЛЕДУЕТ содержать объект, включающий список характеристик и адресов, из которого пользователь или агент пользователя может выбрать один наиболее подходящий. Формат объекта определяется медиа типом, указанным в поле заголовка Content-Type. В зависимости от формата и возможностей агента пользователя, выбор наиболее подходящего представления может выполняться автоматически. Однако, эта спецификация не определяет какого-либо стандарта для автоматического выбора.

Если сервер имеет представление по умолчанию (наиболее предпочтительное), то ему СЛЕДУЕТ включить URL этого представления в поле Location; агенты пользователя МОГУТ использовать значение поля Location для автоматической переадресации. Этот ответ является кэшируемым, если не обозначено иного.

10.3.2 301 Постоянно перенесен, Moved Permanently.

Запрошенному ресурсу был назначен новый постоянный URI, и любые будущие ссылки на этот ресурс СЛЕДУЕТ выполнять, используя один из возвращенных URI. Клиентам с возможностями редактирования связей СЛЕДУЕТ автоматически переопределить ссылки на запрашиваемый URI (Request-URI), используя одну или несколько новых ссылок, возвращенных сервером в тех местах, где это возможно. Этот ответ является кэшируемым, если не обозначено иного.

Если код состояния 301 был получен в ответ на запрос, отличный от GET или HEAD, агент пользователя НЕ ДОЛЖЕН автоматически переназначать запрос, пока нет подтверждения пользователя, так как иначе условия запроса изменятся.

Обратите внимание: При автоматическом переназначении запроса POST после получения кода состояния 301, некоторые существующие HTTP/1.0 агенты пользователя ошибочно изменят метод запроса на GET.

10.3.3 302 Временно перемещен, Moved Temporarily.

Запрошенный ресурс временно находится под другим URI. Так как переадресация может быть изменена в любой момент, клиенту СЛЕДУЕТ продолжать использовать запрашиваемый URI (Request-URI) в будущих запросах. Кэшируемость этого ответа зависит только от содержимого полей заголовка Cache-Control или Expires (если этих полей нет, то ответ не кэшируется).

Если код состояния 302 был получен в ответ на запрос, отличный от GET или HEAD, агент пользователя НЕ ДОЛЖЕН автоматически переназначать запрос, пока нет подтверждения пользователя, так как иначе условия запроса изменятся.

Обратите внимание: При автоматическом переназначении запроса POST после получения кода состояния 302, некоторые существующие HTTP/1.0 агенты пользователя ошибочно изменят метод запроса на GET.

10.3.4 303 Смотреть другой, See Other.

10.3.5 304 Не модифицирован, Not Modified.

Если клиент выполнил условный GET запрос, и доступ разрешен, но документ не изменился, то серверу СЛЕДУЕТ ответить, используя этот код состояния. Ответ НЕ ДОЛЖЕН содержать тела сообщения.

Если условный GET использует строгое сравнение кэша (strong cache validator) (смотреть раздел 13.3.3), ответу НЕ СЛЕДУЕТ содержать других заголовков объекта (entity-headers). Иначе (то есть, если условный GET использует слабое сравнение (weak validator)), ответ НЕ ДОЛЖЕН содержать других заголовков объекта; это предотвращает несогласованности между кэшированными телами объектов (entity-bodies) и модифицированными заголовками.

Если ответ с кодом состояния 304 указывает объект, в настоящее время не кэшированный, то кэш ДОЛЖЕН игнорировать ответ и повторить запрос без условного выражения.

Если кэш использует полученный ответ с кодом состояния 304 для модифицикации вхождения кэша, кэш ДОЛЖЕН модифицировать вхождение так, чтобы отразить любые новые значения полей, данные в ответе.

Ответ с кодом состояния 304 НЕ ДОЛЖЕН включать тела сообщения (message-body), и, таким образом, всегда завершается первой пустой строкой после полей заголовка.

10.3.6 305 Используйте прокси-сервер, Use Proxy.

Обращение к запрошенному ресурсу ДОЛЖНО производиться через прокси-сервер, указанный в поле Location. В поле Location указан URL прокси-сервера. Ожидается, что получатель повторит запрос через прокси-сервер.

Класс кодов состояния 4xx предназначен для случаев, когда клиент, возможно, допустил ошибку. За исключением ответа на запрос HEAD, серверу СЛЕДУЕТ включить объект, содержащий объяснение ошибочной ситуации, и объяснение, является ли она временной или постоянной. Эти коды состояния применимы к любому методу запроса. Агентам пользователя СЛЕДУЕТ показывать пользователю любой включенный объект.

Обратите внимание: Если клиент посылает данные, то реализации сервера, использующей TCP, следует гарантировать, что клиент подтвердил получение пакета(ов), содержащего ответ, прежде чем сервер закроет соединение. Если клиент продолжает посылать данные серверу после закрытия соединения, TCP стек сервера пошлет пакет сброса (RST) клиенту, а TCP стек клиента, в свою очередь, может стереть клиентские неподтвержденные входные буфера прежде, чем они будут прочитаны и интерпретированы приложением HTTP.

10.4.1 400 Испорченный Запрос, Bad Request.

Запрос не может быть понят сервером из-за malformed синтаксиса. Клиенту НЕ СЛЕДУЕТ повторять запрос без модификаций.

10.4.2 401 Несанкционированно, Unauthorized.

Запрос требует установления подлинности пользователя. Ответ ДОЛЖЕН включать поле заголовка WWW-Authenticate (раздел 14.46), содержащее вызов (challenge), применимый к запрошенному ресурсу. Клиент МОЖЕТ повторить запрос с подходящим полем заголовка Authorization (раздел 14.8). Если запрос уже включает рекомендации установления подлинности (Authorization credentials) в поле Authorization, то ответ с кодом состояния 401 указывает, что в установлении подлинности этим рекомендациям отказано. Если ответ с кодом состояния 401 содержит тот же самый вызов, что и предшествующий ответ, а агент пользователя уже делал попытку установления подлинности по крайней мере один раз, то СЛЕДУЕТ показать пользователю объект, который был дан в ответе, так как этот объект МОЖЕТ включать relevant диагностическую информацию. Установление подлинности доступа в протоколе HTTP описывается в разделе 11.

10.4.3 402 Требуется оплата, Payment Required.

Этот код зарезервирован для будущего использования.

10.4.4 403 Запрещено, Forbidden.

Сервер понял запрос, но отказывается выполнять его. Установление подлинности (Authorization) не поможет, и запрос НЕ ДОЛЖЕН быть повторен. Если метод запроса не HEAD и сервер желает указать, почему запрос не был выполнен, ему СЛЕДУЕТ описать причину отказа в объекте. Этот код состояния обычно используется, когда сервер не желает указывать точную причину отказа, или когда никакой другой ответ не подходит.

10.4.5 404 Не найден, Not Found.

Сервер не нашел ничего, соответствующего данному запрашиваемому URI (Request-URI). Никак не сообщается является ли такое положение временным или постоянным.

Если сервер не желает делать данную информацию доступной клиенту, то вместо этого кода состояния может использоваться код состояния 403 (Запрещено, Forbidden). Код состояния 410 (Удален, Gone) СЛЕДУЕТ использовать, если сервер знает через некоторый внутренне конфигурируемый механизм, что старый ресурс более недоступен, но не знает нового адреса для пересылки.

10.4.6 405 Метод не дозволен, Method Not Allowed.

Метод, определенный в строке запроса (Request-Line) не дозволено применять для ресурса, идентифицированного запрашиваемым URI (Request-URI). Ответ ДОЛЖЕН включать заголовок Allow, содержащий список допустимых методов для запрошенного ресурса.

10.4.7 406 Не приемлем, Not Acceptable.

Ресурс, идентифицируемый запросом, имеет возможности генерации только таких объектов ответа, которые имеют характеристики содержимого (content characteristics), не согласующиеся с заголовками приема (accept headers), представленными в запросе.

Если это был не запрос HEAD, то в ответ СЛЕДУЕТ включить объект, содержащий список доступных характеристик объекта и адреса (locations), из которых пользователь или агент пользователя может выбрать наиболее подходящий. Формат объекта определеятся медиа типом, представленным в поле заголовка Content-Type. В зависимости от формата и возможностей агента пользователя, выбор наиболее подходящего варианта может выполняться автоматически. Однако, эта спецификация не определяет никакого стандарта для автоматического выбора.

Обратите внимание: HTTP/1.1 серверы позволяют возвращать ответы, которые не приемлемы согласно заголовкам приема (accept headers), представленным в запросе. В некоторых случаях, это может быть даже предпочтительно по сравнению с посылкой ответа с кодом состояния 406. Агентам пользователя неплохо бы рассматривать заголовки поступившего ответа, чтобы определить, является ли он приемлемым. Если ответ недопустим, агенту пользователя СЛЕДУЕТ временно остановиться, чтобы получить больше данных и спросить пользователя о дальнейших действиях.

10.4.8 407 Требуется установление подлинности через прокси-сервер, Proxy Authentication Required.

Этот код подобен коду 401 (Несанкционированно, Unauthorized), но указывает, что клиент ДОЛЖЕН сначала установить свою подлинность (authenticate) прокси-серверу. Прокси-сервер ДОЛЖЕН возвратить поле заголовка Proxy-Authenticate (раздел 14.33), содержащее вызов (challenge), применяемый прокси-сервером для запрошенного ресурса. Клиент МОЖЕТ повторить запрос с подходящим полем заголовка Proxy-Authorization (раздел 14.34). Установление подлинности доступа в протоколе HTTP описывается в разделе 11.

10.4.9 408 Истекло время ожидания запроса, Request Timeout.

Клиент не произвел запрос в течение времени, которое сервер готов ждать. Клиент МОЖЕТ повторить запрос без модификаций позже.

10.4.10 409 Конфликт, Conflict.

Запрос не был выполнен из-за конфликта с текущим состоянием ресурса. Этот код позволяется только в ситуациях, когда ожидается, что пользователь может решить конфликт и повторно передать запрос. Телу ответа СЛЕДУЕТ содержать достаточное количество информации для пользователя, чтобы он мог распознать источник конфликта. В идеале, объект ответа должен включать достаточно информации для пользователя или агента пользователя для решения проблемы; однако это может не быть возможно, да и не требуется.

Конфликты, наиболее вероятно, будут возникать в ответ на запрос PUT. Если используется версификация, и объект, который должен быть помещен, включает изменения ресурса, которые находятся в противоречии со сделанными раньше каким-либо запросом (третьей стороны), сервер МОЖЕТ использовать ответ с кодом состояния 409, чтобы показать, что он не может выполнить запрос. В этом случае, объекту ответа СЛЕДУЕТ содержать список отличий двух версий в формате, определенном полем заголовка ответа Content-Type.

10.4.11 410 Удален, Gone.

Запрошенный ресурс больше не доступен на сервере, и нет никакого адреса для перенаправления запроса. Такое состояние СЛЕДУЕТ рассматривать как постоянное. Клиентам с возможностями редактирования гиперсвязей СЛЕДУЕТ удалить ссылки на запрашиваемый URI (Request-URI) после одобрения пользователем. Если сервер не знает, или не может определить, является ли такое положение постоянным или нет, то ему СЛЕДУЕТ вместо этого кода использовать код состояния 404 (Не найден, Not Found). Этот ответ является кэшируемым, если не обозначено иного.

10.4.12 411 Требуется длина, Length Required.

Сервер отказывается принимать запрос с неопределенным Content-Length. Клиент МОЖЕТ повторить запрос, если добавит допустимое поле заголовка Content-Length, содержащее длину тела сообщения (message-body) в сообщении запроса.

10.4.13 412 Предусловие неверно, Precondition Failed.

Предусловие, представленное одним или несколькими полями заголовка запроса (request-header), оказалось ложным при проверке сервером. Этот код ответа позволяет клиенту поместить предусловия на текущую метаинформацию ресурса (данные полей заголовка) и, таким образом, предотвратить применение запрошенного метода к ресурсу, отличному от того, для которого предназначен метод.

10.4.14 413 Объект запроса слишком большой, Request Entity Too Large.

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

Если это временное состояние, то серверу СЛЕДУЕТ включить поле заголовка Retry-After для указания времени, через которое клиент может снова повторить запрос.

10.4.15 414 URI запроса слишком длинный, Request-URI Too Long.

Сервер отказывается обслуживать запрос, потому что запрашиваемый URI (Request-URI) длиннее, чем сервер желает интерпретировать. Это редкое состояние, которое, по всей вероятности, происходит только тогда, когда клиент неправильно преобразовал запрос POST к запросу GET с длинной информацией запроса, либо когда клиент попал в «черную дыру» URL перенаправления (например, перенаправленный URL префикс указывает на свой суффикс), или когда на сервер производится нападение клиентом, пытающимся эксплуатировать лазейки в секретности, имеющиеся в некоторых серверах, использующих буфера фиксированной длины для чтения или манипулирования с запрашиваемым URI (Request-URI).

10.4.16 415 Неподдерживаемый медиа тип, Unsupported Media Type.

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

Коды состояния, начинающиеся с цифры «5» указывают случаи, в которых сервер знает, что допустил ошибку или неспособен выполнить запрос. Отвечая на запрос, за исключением запроса HEAD, серверу СЛЕДУЕТ включить объект, содержащий объяснение ошибочной ситуации и информацию, является ли это положение временным или постоянным. Агентам пользователя СЛЕДУЕТ показывать пользователю любой включенный объект. Эти коды состояния применимы к любому методу запроса.

10.5.1 500 Внутренняя ошибка сервера, Internal Server Error.

Сервер столкнулся с непредвиденным условием, которое не позволяет ему выполнить запрос.

10.5.2 501 Не реализовано, Not Implemented.

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

10.5.3 502 Ошибка шлюза, Bad Gateway.

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

10.5.4 503 Сервис недоступен, Service Unavailable.

Сервер в настоящее время не способен обработать запрос из-за временной перегрузки или обслуживания сервера. Это временное условие, которое будет облегчено после некоторой задержки. Если известна продолжительность задержки, она может быть указана в заголовке Retry-After. Если Retry-After не присутствует в ответе, клиенту СЛЕДУЕТ обрабатывать этот ответ как ответ с кодом 500.

Обратите внимание: существование кода состояния 503 не подразумевает, что сервер должен использовать его, когда перегружен. Некоторые сервера могут просто закрывать соединение.

10.5.5 504 Истекло время ожидания от шлюза, Gateway Timeout.

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

10.5.6 505 Не поддерживаемая версия HTTP, HTTP Version Not Supported.

Сервер не поддерживает, или отказывается поддерживать, версию HTTP протокола, которая используется в сообщении запроса. Сервер указывает, что не способен или не желает выполнять запрос, используя ту же самую major версию, что и клиент, как описано в разделе 3.1, в других сообщениях. Ответу СЛЕДУЕТ содержать объект, описывающий, почему эта версия не поддерживается, и какие другие протоколы поддерживаются этим сервером.

Список кодов состояния HTTP

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

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

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

Содержание

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

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

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

Информационные [ править ]

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

Успех [ править ]

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

Перенаправление [ править ]

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

Ошибка клиента [ править ]

Ошибка сервера [ править ]

См. также [ править ]

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

Ссылки [ править ]

Основные документы по протоколу HTTP (по убыванию даты публикации):

Документы по расширениям и обновлениям протокола HTTP (по убыванию даты публикации):

After a POST, should I do a 302 or a 303 redirect?

A common scenario for a web app is to redirect after a POST that modifies the database. Like redirecting to the newly created database object after the user creates it.

It seems like most web apps use 302 redirects, but 303 seems to be the correct thing to do according to the specification if you want the url specified in the redirect to be fetched with GET. Technically, with a 302, the browser is supposed to fetch the specified url with the same method that the original url was fetched with, which would be POST. Most browsers don’t do that though.

So should I be using 302 or 303?

5 Answers 5

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

The correct one is 303.

I use it and haven’t found any compatibility problems with UAs newer than Netscape 4 (1998, released 17 years ago).

If you use 302, you’re risking that UA will re-send POST to the new URL instead of switching to GET.

Still, if you’re worried about HTTP/1.0 clients (which don’t support vhosts and probably won’t be able to access your page anyway) then you should include HTML with link to the new page in body of the 303 response (web servers like Apache do that already).

Depends.
303 and 307 responses were added in HTTP1.1.
So client agents that are strictly compliant to HTTP1.1 RFC should be fine with a 303 response.
But there can be agents that are not fully conformant or are HTTP1.0 compliant and will not be able to handle the 303.
So to be sure that the response of your application can be handled gracefully by the majority of client implementations I think 302 is the safest option.
Excerpt from RFC-2616:

Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.

In most server-side languages the default redirection mechanism uses 302:

So I’d prefer this, rather than setting status and headers manually.

In theory, you (and all the world) should be using 303 as you have noted. But also, most browsers react to a 302 like they should react to a 303. So, overall, it seems that it won’t matter if you send 302 or 303. In the link you provided for the 303 specification, theres an interesting note:

Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.

It’s important to note the pre-HTTP/1.1 user agents, so maybe this was important a while ago, but I don’t believe it is the case now.

So, all in all, it’s up to you (I could bet whatever you want that browsers won’t change their behavior against 302 statuses never, for fear of breaking the internet for their users).

How to Fix HTTP 302 Error: 5 Methods + Error Variations and SEO Impact Explained

Web browsers and web servers communicate using an application protocol called the Hypertext Transfer Protocol (HTTP). Every time visitors access a website, the web browser sends a request to the web server for resources, allowing them to view the content.

However, in the case of an error, web browsers will send back a blank page with an HTTP code instead of the website content. One of the HTTP status codes you might encounter during website development is the 302 found redirect, which generates a temporary redirection.

Typically, website owners use this redirect to drive traffic to a new URL whenever the website is under heavy maintenance. However, due to the complexity of HTTP status codes, the server and client may process the incorrect 302 response code.

With this in mind, we will go over the steps to diagnose and troubleshoot unexpected 302 errors on your website. We will also take a look at the impact they can have on your website’s SEO.

First, let’s start with a more detailed explanation of the HTTP 302 redirect.

What Is the HTTP 302 Error?

Status codes indicate whether the HTTP request was successful. To help you identify them correctly, take a look at the five HTTP status codes below:

Therefore, an HTTP status code that starts with “3” indicates that your web browser needs to take further actions to fulfill the request.

The HTTP 302 error occurs when the requested resource has been temporarily moved to a new location. Hence, the system automatically redirects visitors to a new URL that has the resource.

The HTTP redirect starts when the web server hosting the content returns a 3xx status code and a location header that holds the new URL. Once the web browser receives this response, it automatically loads the new URL instead of displaying the 404 error not found error.

Since the current redirection directive can change, the web server should keep the initial URL to process future requests. This prompts the user agent or web browser to deliver the original request to the URL attached in the location header.

One of the most common usages of the HTTP 302 status code is localization. For example, when you access https://www.google.com/, the browser will redirect you to the localized version of Google, depending on your country.

So, if you live in India, the response 302 found will take you to https://www.google.co.in/ for easier access to local content. Big companies like eBay and Amazon also use 302 redirects to drive traffic to a local server.

5 Methods to Fix the Status Code 302 Error

The 302 found server response specifies that the requested resource has been moved temporarily to a new location. That said, a server can misunderstand and send incorrect HTTP 302 errors instead of passing an informational or successful request.

For this reason, we have included the five methods to diagnose which component of your website is sending the improper 302 found response, along with the steps to fix it.

1. Restore the Site From a Backup

Creating a full backup of a website before making any changes to the system is crucial.

A reliable backup can save your website from data loss, security breaches, and malware infection. On that note, the first step you can take is to restore your site to its stable state.

Clicking on it will present various types of backups saved on the server. If you use WordPress or another Content Management System (CMS), you will need to restore both your website files and the MySQL database.

To start, click on the Files backups button and click on Show files. If you want to restore the whole website, choose the public_html folder and click Restore files.

The next step is to restore your database. Start by selecting the Database backups option, choose the database to restore, and click Show databases.

You will see a list of available backup dates – choose your desired date, and click Restore.

The system will start downloading the backups and notify you once it’s done.

After the restoration process is complete, all the changes made until the backup date will be reverted. Hence, the HTTP 302 Error should be gone.

2. Deactivate Outdated Software

Internet standards are documented by a Request for Comment (RFC). On this note, the RFC specification for HTTP 1.0 states that the response 302 found code’s function is to command the web browser to do a temporary redirection.

If the HTTP 302 status code is delivered through the post request, the web browser should not redirect content without the user’s confirmation. However, many modern browsers automatically process this HTTP error code 302 as a GET request.

Whenever this happens, the web server software processing the request can’t perform the correct redirection. As a result, the HTTP 1.1 RFC document includes the 303 See Other to handle post-to-get requests specifically.

For this reason, we recommend deactivating outdated software that is not compliant with the HTTP 1.1 RFC. Doing so will prevent visitors from seeing irrelevant content on your website.

3. Inspect Web Server Configuration

Another step you can take to fix the error 302 redirects is to inspect the web server configuration. The two most popular web server software are Nginx and Apache – hence, your web applications most likely run on one of them.

Below, we will go over the steps of inspecting configuration files in both server programs.

Apache

To identify which web server your website is using, you will need to look for a key file that regulates the website features. With Apache, you can start locating the .htaccess (hypertext access) file on your root directory.

Simply go to your hosting control panel and open the File Manager -> public_html.

Once you have located your .htaccess file, open it using a text editor.

From there, you will see a series of RewriteXXX directives that manage HTTP redirects and permalink structures. Pay particular attention to these two:

If the request has a matching URL, the RewriteRule following the RewriteCond directives will initiate a temporary redirection to the correct URL.

Below is an example of a proper 302 temporary redirect execution:

In the previous example, the combination of RewriteCond and RewriteRule matches the requests to website.com. Hence, the system generates a temporary redirection to the same URL on the temporary-website.com domain.

Note the extra flag following the RewriteRule directive – it indicates that the response code delivered has to be a 302 found. This prompts the user agents to do a temporary redirect.

If there are any odd rewrite directives in the .htaccess file, go ahead and comment on it. Do so by adding a # prefix in front of the line that you comment on. Once you’re done, try restarting the web server to see if the error 302 has been resolved.

Nginx

If your web server is running on Nginx, you need to locate a different key file. Instead of an .htaccess file, look for the nginx.conf file located in the following directories:

Once you have found the file, open it through the text editor, and look for rewrite directives that include a redirect flag.

To understand the way the Nginx system works, take a look at the example of ablock directive below:

Rewrite directives in Nginx work similarly to those in Apache. A set of directives in the example above regulates a virtual server by generating a temporary HTTP redirection from example.com to temporary-example.com.

To ensure everything works properly on your Nginx server, try to spot any unusual rewrite directives that contain a redirect flag. Comment on such lines, and restart the system to see if the problem has been resolved.

4. Clear Error Logs

Recent changes and updates on a website can also cause the 302 found error. Thus, after completing one, don’t forget to check your website’s error log.

Most web applications will have server logs connected to the actual hardware they’re running on. These logs record every activity performed on the servers, from providing a history of the requested pages to collecting user-specific information.

Typically, hosting providers will give access to activate server logs through users’ hosting control panel. However, you can also enable error logging on your WordPress site using the WP_DEBUG PHP constant, which generates the debugging process throughout the website.

To begin, copy and paste the following lines in your wp-config.php file:

Once you’re done, all of the recorded errors will appear in the wp-content/debug.log file, making it easier for you to pinpoint which component is causing the unexpected temporary redirects.

Pro Tip

You can manually locate applications on your server and go through all application logs. This helps you determine irregularities in the application code and shows you what causes the 302 response code to appear.

Additionally, if you want to check the error log on your virtual server software, access the following file accordingly:

5. Uninstall or Temporarily Disable New Plugins or Themes

The most common cause of website errors in WordPress is conflicting plugins or themes. In some cases, a plugin might try to set up redirects that conflict with default WordPress redirects. Thus, generating an incorrect HTTP response code.

One effective way to solve this problem is by temporarily disabling plugins on your website. To do so, go to the wp-content directory and rename the plugins folder – for example, plugins-disable.

If your website is back to normal without active plugins, the next thing to do is finding which plugin causes the HTTP 302 error. Begin with renaming the plugins directory back to the original and activate the plugins one by one.

When the 302 error appears, you have detected the faulty plugin – uninstalling it should remove the error. However, if the method above yields no results, try following the same steps with your WordPress themes.

When to Use the 302 Temporary Redirect?

Essentially, an HTTP 302 response is meant for redirection rather than it being an error. Unless the server is delivering an incorrect response, the cause of 302 temporary redirects is mostly intentional.

Below are some of the most common reasons to use the 302 found responses:

Pro Tip

To perform permanent redirection, you should redirect your website using the 301 Redirect. The most notable features of this redirection are keeping all SEO values from your old page and transferring them to the new URL.

The 302 Status Code and SEO

When implemented correctly, the 302 found redirect will not hurt your site’s SEO. In fact, it plays an important role in preserving the SEO value of a website page.

The HTTP 302 redirect tells Google and other search engines that the redirection is only temporary – preventing them from deindexing the original resource. Thus, allowing you to retain SEO value like ranking and domain authority the original page might have.

However, a problem occurs when you unintentionally use the 302 redirect to move a website resource permanently. Google search engine will continue indexing the old page and ignoring the new page. Moreover, since the search engine won’t transfer any SEO value, the new page won’t have the same value as the original page.

Pro Tip

Use HTTP 302 redirects only if you plan to bring the old page back. Additionally, avoid moving SEO-weight content to a new location as doing so might affect page ranking on the SERPs.

How to Diagnose If Your Site Has the 302 Error

To identify whether your website is experiencing error 302, start by entering the original URL into the address bar and observing the URL. If your original URL changes into your destination URL, it means that the HTTP redirection is working correctly.

On the other hand, if the address stays the same, you need to identify the cause. Start by cleaning your browser cache to see whether doing so triggers the URL to change. If nothing happens, try to implement the methods we have talked about in the previous section.

Further Reading

Conclusion

The HTTP error code 302 found indicates that a specific URL has been moved temporarily to a new location. Whenever visitors, Google robots, or other search engines access the original URL, 302 redirect delivers an automatic response indicating a new address.

The 302 redirects can benefit a website on several occasions. That said, if the web server hosting your website generates an unexpected response 302 found, it may hinder your site’s ability to satisfy visitors’ requests.

Let’s recap the steps of troubleshooting this issue:

Apart from the 302 error, you may encounter other status codes, such as the 403 forbidden error or the 504 gateway timeout. We recommend learning more about these errors so that you can fix them in a timely manner and ensure your website performance is back on track as soon as possible.

What happens when a browser encounters a 302 header status code?

Does the browser make a new request to the location given in the header?

I ask because I was playing around with Fiddler and noticed when I make a request to a page that returns a 302 HTTP code, there are two entries in the network log. The first is to the initial URL, and the second is to the new location given in the response header of the first request.

I’m just curious if web browsers work the same way, but just hide the first response from the user.

1 Answer 1

Yes, the browser works in very much similar fashion. You can try requesting a url in Chrome, possibly the one you tried in Fiddler. The Network Log of chrome would show you two requests.

The RFC description of HTTP status code can be read over here,

Quoting from there only, regarding the 302 status code:

RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

When a server responds with a 302 status code, it send back the newer url (to which the current requested old url is to be redirected) to the requesting user-agent (likely a browser). Now, as per the RFC document, the user agent must not request the newer url for 302 status code. Yet most of them do make a second request.

Коды ответа 301, 302 и 304

Код 301 Moved Permanently

Переводится, как «перемещено навсегда», сообщает клиенту о том, что документ по запрашиваемому адресу был перемещен. Сервер перенаправляет пользователя на другую страницу.

Проверить код ответа страницы можно через сервис Яндекса (webmaster.yandex.ru/tools/server-response).

Данный код используется для редиректа одной страницы на другую.

Ситуации, когда используется такой редирект:

Код 302 Moved Temporarily

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

Случаи, когда используется данный вид редиректа:

Код 304 Not Modified

Переводится, как «не модифицирован», появляется если страница, картинка или любой статический файл, который запрашивается, не изменялся с определенного времени и он может быть использована браузером. Ускоряет время загрузки страниц, которые не изменялись.

Загрузка страницы происходит из кэша, поэтому нет необходимости повторно передавать запрашиваемые ресурсы через всю сеть.

коды ответа сервера

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

403 Access allowed only for registered users

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

В настоящее время выделено пять классов кодов состояния:

Ниже, представлены коды ответа из реестра кодов состояния IANA.

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

100 Continue
(русск. Продолжать)
Сервер удовлетворён начальными сведениями о запросе. Клиент может продолжать пересылать заголовки.

101 Switching Protocols
(русск. Переключение протоколов)
Сервер предлагает перейти на более подходящий для указанного ресурса протокол. Список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола.

102 Processing
(русск. Идёт обработка)
Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме.

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

200 OK
(русск. Хорошо)
Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения.

201 Created
(русск. Создано)
В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ 202.

202 Accepted
(русск. Принято)
Запрос был принят на обработку, но обработка не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс.

203 Non-Authoritative Information
(русск. Неавторитетная информация)
Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной.

204 No Content
(русск. Нет содержимого)
Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные.

205 Reset Content
(русск. Сбросить содержимое)
Сервер обязывает клиента спросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно.

206 Partial Content
(русск. Частичное содержимое)
Сервер удачно выполнил запрос клиента, но передал только часть документа. Такой ответ сервер может отправить если в заголовке запроса клиента есть поле Content-Range. Особое внимание при работе с подобными ответами следует уделить кэшированию.

207 Multi-Status
(русск. Многостатусный)
Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с единственным объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности.

226 IM Used
(русск. IM использовано)
Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров.

Коды статуса класса 3xx сообщают клиенту что для успешного выполнения операции нужно произвести следующий запрос к другому URI. В большинстве случаев новый адрес указывается в поле Location заголовка. Клиент в этом случае должен, как правило, произвести автоматический переход (жарг. редирект).

Обратите внимание, что при обращении к следующему ресурсу можно получить ответ из этого же класса кодов. Может получиться даже длинная цепочка из перенаправлений, которые, если будут производится автоматически, создадут чрезмерную нагрузку на оборудование. Поэтому разработчики протокола HTTP настоятельно рекомендуют после второго подряд подобного ответа обязательно запрашивать подтверждение на перенаправление у пользователя (раньше рекомендовалось после 5-го). За этим следить обязан клиент, так как текущий сервер может перенаправить клиента на ресурс другого сервера. Клиент также должен предотвратить попадание в круговые перенаправления.

300 Multiple Choices
(русск. Несколько выборов)
По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту или пользователю.

301 Moved Permanently
(русск. Перемещёно окончательно)
Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. При запросах не методом HEAD сервер должен передать в теле сообщения гипертекстовое пояснение. При использовании всех методов, кроме GET и POST, предварительно следует уведомить пользователя об изменении ссылки. Не стоить забывать, что некоторые агенты ошибочно меняют метод POST на GET после перехода на другой адрес.

302 Found
(русск. Найдено)
Запрошенный документ был временно перенесен на другой URI, указанный в заголовке в поле Location. При всех методах кроме HEAD сервер должен передать в теле гипертекстовое пояснение. При использовании всех отличных от GET и POST методов предварительно следует уведомить пользователя об изменении URI. При обращении к следующему ресурсу метод POST на GET менять следует как это делают некоторые агенты.

303 See Other
(русск. Смотреть другое)
Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET не смотря даже на то, что первый запрашивался методом POST. Если используется не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание.

304 Not Modified
(русск. Не изменено)
Сервер возвращает такой код, если клиент запросил документ методом GET, в заголовке использовал поле Date и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела.

305 Use Proxy
(русск. Использовать прокси)
Запрос к запрашиваемому ресурсе должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только родные HTTP-сервера (не прокси).

306 (Reserved)
(русск. Зарезервировано)
Использовалось раньше. В настоящий момент зарезервировано.

307 Temporary Redirect
(русск. Временное перенаправление)
Запрашиваемый ресурс короткое время доступен только по другому URI (указывается в поле Location заголовка). Если был послан не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание. При использовании всех методов кроме GET и POST предварительно следует уведомить пользователя о временном изменении ссылки.

4xx: Client Error

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

400 Bad Request
(русск. Плохой запрос)
Запрос не понят сервером из-за наличия синтаксической ошибки. Клиенту следует повторно обратиться к ресурсу с изменённым запросом.

401 Unauthorized
(русск. Неавторизован)
Запрос требует идентификации пользователя. Клиент должен запросить имя и пароль у пользователя и передать их в записи WWW-Authenticate заголовка в следующем запросе. В случае ввода ошибочных данных сервер снова вернёт этот же статус.

402 Payment Required
(русск. Необходима оплата (зарезервировано))
Предполагается использовать в будущем. В настоящий момент не используется.

403 Forbidden
(русск. Запрещено)
Сервер понял запрос, но он отказывается его выполнять из-за каких-то ограничений в доступе. Идентификация через протокол HTTP здесь не поможет. Скорее всего, на сервере нужно провести аутентификацию другим способом, сделать запрос с определёнными параметрами или удовлетворить каким-либо условиям.

404 Not Found
(русск. Не найдено)
Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410 вместо этого. Этот код может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы.

405 Method Not Allowed
(русск. Метод не поддерживается)
Указанный клиентом метод нельзя применить к ресурсу. Сервер также должен передать в заголовке ответа поле Allow со списком доступных методов.

406 Not Acceptable
(русск. Не приемлемо)
Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса.

407 Proxy Authentication Required
(русск. Необходима авторизация прокси)
Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на обычном сервере.

408 Request Timeout
(русск. Время ожидания истекло)
Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время.

409 Conflict
(русск. Конфликт)
Запрос не может выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.

410 Gone
(русск. Удалён)
Такой ответ сервер посылает, когда ресурс раньше был по указанному URI, но был удалён и теперь недоступен. Серверу в этом случае не известно и местоположение альтернативного документа (например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404.

411 Length Required
(русск. Необходима длина)
Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI.

412 Precondition Failed
(русск. Условие «ложно»)
Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.

413 Request Entity Too Large
(русск. Запрашиваемые данные слишком большие)
Возвращается если сервер по каким-то причинам не может передать запрашиваемый объём информации. Если проблема временная, то сервер может в ответе указать в поле Retry-After время, по истечении которого можно повторить аналогичный запрос.

414 Request-URI Too Long
(русск. Запрашиваемый URI слишком длинный)
Сервер не может обработать запрос из-за слишком длинного указанного URI. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST.

415 Unsupported Media Type
(русск. Неподдерживаемый тип данных)
По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе.

416 Requested Range Not Satisfiable
(русск. Запрашиваемый диапазон не достижим)
В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges.

417 Expectation Failed
(русск. Ожидаемое ошибочно)
По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса.

422 Unprocessable Entity
(русск. Необрабатываемый экзмепляр)
Сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка из-за которой невозможно произвести операцию над ресурсом.

423 Locked
(русск. Заблокировано)
Целевой ресурс из запроса заблокирован от применения к нему указанного метода.

424 Failed Dependency
(русск. Невыполненная зависимость)
Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт код 424.

426 Upgrade Required
(русск. Необходимо обновление)
Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection.

5xx: Server Error

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

500 Internal Server Error
(русск. Внутренняя ошибка сервера)
Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса 5xx.

501 Not Implemented
(русск. Не выполнимо)
Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод.

502 Bad Gateway
(русск. Плохой шлюз)
Сервер в роли шлюза или прокси получил сообщение о неудачном выполнении промежуточной операции.

503 Service Unavailable
(русск. Сервис недоступен)
Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным является сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов.

504 Gateway Timeout
(русск. Шлюз не отвечает)
Сервер в роли шлюза или прокси не дождался ответа от вышестоящего сервера для завершения текущего запроса.

505 HTTP Version Not Supported
(русск. Версия HTTP не поддерживается)
Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.

506 Variant Also Negotiates (Experimental)
(русск. Вариант тоже согласован (экспериметальное))
В результате ошибочной конфигурации выбранный вариант указывает сам на себя из-за чего процесс связывания прерывается.

507 Insufficient Storage
(русск. Закончилось место)
Не хватает места для выполнения текущего запроса. Проблема может быть временной.

510 Not Extended
(русск. Не расширено)
На сервере отсутствует расширение, которое планирует использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях.

Что точно значит HTTP/1.1 302?

Какая-то статья, которую я читал, когда-то говорила, что это значит прыгать (из одного URI в другой), но я обнаружил эту «302» даже тогда, когда собственно прыгать вообще не было!

16 ответов

А 302 редирект означает, что страница была временно перемещена, в то время как 301 означает, что она была перманентно перемещена.

Этот вопрос был задан давно, пока еще висели RFC 2616. Некоторые ответы на этот вопрос основаны на таком документе, который уже не актуален в наши дни. Цитируя марка Ноттингема, который на момент написания сопредседателей рабочих групп IETF HTTP и QUIC:

Don’t use RFC2616. Удалите его со своих жестких дисков, закладок, и сожмите (или ответственно переработайте) любые копии, которые распечатываются.

Старый RFC 2616 был заменен следующими документами, которые вместе определяют протокол HTTP/1.1:

Поэтому я нацелен на предоставление ответа, основанного на коде состояния RFC 7231 который является текущим референсом для кодов состояния HTTP/1.1.

Код состояния 302

Веб-браузеры могут меняться с указания POST на указание GET в последующем запросе. Если это поведение нежелательно, вместо него может использоваться заголовок у 307 (Temporary Redirect).

Вот так определяется код состояния у 302 в заголовке RFC 7231 :

Код состояния 302 (Found) указывает, что целевой ресурс временно проживает под другим URI. Так как перенаправление может быть изменено по случаю, клиент должен продолжать использовать эффективный URI запроса для будущих запросов.

Note: По историческим причинам пользовательский агент MAY меняет метод запроса с POST на GET для последующего запроса. Если это поведение нежелательно, вместо него может использоваться код состояния 307 (Temporary Redirect).

Согласно веб-докам MDN от Mozilla, типичный случай использования для 302 такой:

Веб-страница временно недоступна по причинам, которые не были непредвиденными. Таким образом, поисковики не обновляют свои ссылки.

Другие коды состояния для перенаправления

В документе RFC 7231 определены следующие коды состояния для перенаправления:

У меня проблема с нашим сайтом, в homepage он работает соотвественно но когда я посещаю внутренные страницы он возвращает 302 Found и держится на перенаправлении, я использовал логи в inspector element. В хроме он рабочий, но в ie11 и firefox он держится на перенаправлении. Вот мой htaccess.

Простой способ посмотреть на HTTP 301 vs. 302 редиректы это:

Допустим у вас закладка до «http://sample.com/sample». Вы используете браузер для перехода туда.

A 302 редирект на другой URL в этот момент означал бы что вам следует держать вашу закладку до «http://sample.com/sample». Это потому что URL назначения может измениться в будущем.

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

What does HTTP/1.1 302 mean exactly?

Some article I read once said that it means jumping (from one URI to another), but I detected this «302» even when there was actually no jumping at all!

16 Answers 16

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

A 302 redirect means that the page was temporarily moved, while a 301 means that it was permanently moved.

301s are good for SEO value, while 302s aren’t because 301s instruct clients to forget the value of the original URL, while the 302 keeps the value of the original and can thus potentially reduce the value by creating two, logically-distinct URLs that each produce the same content (search engines view them as distinct duplicates rather than a single resource with two names).

This question was asked a long ago, while the RFC 2616 was still hanging around. Some answers to this question are based in such document, which is no longer relevant nowadays. Quoting Mark Nottingham who, at the time of writing, co-chairs the IETF HTTP and QUIC Working Groups:

Don’t use RFC2616. Delete it from your hard drives, bookmarks, and burn (or responsibly recycle) any copies that are printed out.

The old RFC 2616 has been supplanted by the following documents that, together, define the HTTP/1.1 protocol:

And, as of June 2022, a new set of RFCs obsoleted the documents listed above:

So I aim to provide an answer based in the RFC 9110, which is the current reference for the HTTP semantics.

The 302 status code

A response with 302 is a common way of performing URL redirection. Along with the 302 status code, the response should include a Location header with a different URI. Such header will be parsed by the user agent and then perform the redirection:

Web browsers may change from POST to GET in the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.

This is how the 302 status code is defined in the RFC 9110:

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

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

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

According to MDN web docs from Mozilla, a typical use case for [ 302 ]302] is:

The Web page is temporarily not available for reasons that have not been unforeseen. That way, search engines don’t update their links.

Other status codes for redirection

The RFC 9110 defines the following status codes for redirection (some of these status codes were originally defined in other RFCs, but have all been consolidated in the RFC 9110):

Do I need to use http redirect code 302 or 307?

Suppose I have a page on my website to show media releases for the current month
http://www.mysite.com/mediareleases.aspx

And for reasons which it’s mundane to go into*, this page MUST be given a query string with the current day of the month in order to produce this list:
http://www.mysite.com/mediareleases.aspx?prevDays=18

As such I need to redirect clients requesting http://www.mysite.com/mediareleases.aspx to http://www.mysite.com/mediareleases.aspx?prevDays=whateverDayOfTheMonthItIs

My question is, if I want google to index the page without the query parameter, should I use status code 302 or 307 to perform the redirect?

4 Answers 4

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

Google’s documentation seems to indicate that both 302 and 307 are treated equivalently, and that «Googlebot will continue to crawl and index the original location.»

But in the face of ambiguity, you might as well dig into the RFCs and try to do the Right Thing, with the naïve hope that the crawlers will do the same. In this case, RFC 2616 § 10.3 contains nearly identical definitions for each response code, with one exception:

302: Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests.

307: Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests.

Which does not strike me as a significant distinction. My reading is that 302 instructs clients that webmasters are untrustworthy, and 307 explicitly tells webmasters that clients will not trust them, so they may freely alter the redirect.

I think the more telling point is the note in 302’s definition:

Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

Which, to me, indicates that 302 and 307 are largely equivalent, but that HTTP/1.0 clients failed to implement 302 correctly the first time around.

Short answer: neither. In most cases the code you really want to use is 303.

For the long answer, first we need some background.

When getting a redirect code the client can (A) load the new location using the same request type or (B) it can overwrite it and use GET.

The HTTP 1.0 spec did not have 303 and 307, it only had 302, which mandated the (A) behavior. But in practice it was discovered that (A) led to a problem with submitted forms.

Say you have a contact form, the visitor fills it and submits it and the client gets a 302 to a page saying «thanks, we’ll get back to you». The form was sent using POST so the thanks page is also loaded using POST. Now suppose the visitor hits reload; the request is resent the same way it was obtained the first time, which is with a POST (and the same payload in the body). End result: the form gets submitted twice (and once more for every reload). Even if the client asks the user for confirmation before doing that, it’s still annoying in most cases.

This problem became so prevalent that client producers decided to override the spec and issue GET requests for the redirected location. Basically, it was an oversight in the HTTP 1.0 spec. What clients needed most was a 303 (and behavior (B) above), but instead they only got 302 (and (A)).

If HTTP 1.0 would have offered both 302 and 303 there would have been no problem. But it didn’t, so it resulted in a 302 which nobody used correctly. So HTTP 1.1 added 303 (badly needed) but also decided to add 307, which is technically identical to 302, but is a sort of «explicit 302»; it says «yeah, I know the issues surrounding 302, I know what I’m doing, give me behavior (A)».

Now, back to our question. You see now why in most cases you will want 303.

Cases where you want to preserve the request type are very rare. And if you do find yourself such a case, the answer is simple: use 302. Either the client speaks HTTP 1.0, in which case it can’t understand 307; or it speaks HTTP 1.1, which means it has no reason to preserve the rebelious behavior of old clients ie. it implements 302 correctly, so use it!

302 redirect and referrer information

i need to do a 302 redirect to a partner company domain. they want to track all of their incoming traffic.

will my index.html 302’d page not pass referrer info?

how do i configure this page to pass the referrer info, if not.

2 Answers 2

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

The referer is sent by the browser, and there is not much you can do about that.

If they really want to track which users came from your website, a solution would be to add a parameter to the URL you are redirecting to.

For instance, instead of redirecting to

You would redirect to something like :

But, of course, this means more work, both on your side and theirs.

302 found response

I have implemented ajax request to populate my drop down fields. It is working Fine but when I stay idle for some time and select some value in drop down the ajax request gets 302 found response. Is it due to session out. Please let me know the solution, can we do some setting that it will never get response as 302 found.

2 Answers 2

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

The 302 status code indicates that the resource you are requesting has redirected to another resource. If this is behind some authentication, or requiring a session to be active then yes, it would follow that the session timing out is responsible for the ajax resource being called to redirect to possibly a login screen maybe.

I would seriously recommend using something like Charles or Fiddler to track the requests being made.

301, 302 или 404? Что применять и в каких случаях?

301 Moved Permanently

301 редирект указывает роботам ПС, что страница перемещена по новому адресу, а старый адрес следует считать устаревшим. Ссылочный вес старого адреса будет передан новому URL.

Стандартные случаи применения 301 редиректа:

В каких ещё случаях целесообразно настроить 301 редирект

– Из товарных карточек

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

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

Прежде чем принять такое решение, нужно провести детальный анализ, описанный в нашей статье «Как не терять трафик из товарных карточек, если товара нет в наличии?»

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

Рекомендуем размещать все правила после следующих строк:

Переадресация домена без www на домен с www:

Переадресация домена с www на без www:

Перенаправление с одной статической страницы на другую:

Редирект на папки без слеша:

Редирект на папки со слешем в конце:

301 редирект с HTTPS-версии на HTTP:

301 редирект с домена на домен:

Перенос изображений на поддомен:

Редирект с поддомена на основной домен второго уровня:

302 Found (HTTP 1.1) / Moved Temporarily (HTTP 1.0)

302 редирект – это временное перенаправление на другой адрес. Он означает, что ресурс временно находится где-то в другом месте, и клиент/браузер должен продолжать запрашивать исходный URL. Из индекса такие страницы не удаляются.

Случаи, в которых целесообразно использовать 302 редирект:

Например, 302 редирект можно использовать для страницы с акционными предложениями в интернет-магазине. Чтобы не переделывать постоянно основную страницу, наполненную контентом и продвигаемую в ПС, можно временно перенаправлять её на страницы со списками свежих акций, которые могут обновляться еженедельно.

404 ошибка: страница не найдена

404 ошибка – это код ответа сервера, который означает, что страница, которую вы запрашиваете, не найдена.

Чаще всего причиной этой ошибки становятся:

Ошибки 404 также могут появиться вследствие некорректной работы сервера, который способен выдавать ошибку даже при работающем ресурсе.

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

Подробное описание, какой должна быть правильная 404 страница.

Что выбрать: 301 или 404?

Каждую ситуацию нужно анализировать индивидуально. Ниже мы собрали несколько популярных вопросов и дали ответы на них.

Вопрос №1

Ответ

Мы рекомендуем настроить код ответа сервера 404. Все несуществующие страницы пагинации должны отдавать 404-й код ответа сервера.

Вопрос №2

Есть интернет-магазин из 4000 страниц. Сотни товаров уже не нужны для продажи и требуется убрать их с сайта. У каждого товара своя страница. Как лучше сделать: поставить 404 код ответа сервера на эти страницы или сделать 301 редирект на главную?

Ответ

Не рекомендуем настраивать 301-й редирект на главную страницу. Для пользователей, ищущих конкретную модель (по ссылке или через закладки), такой редирект будет плохим ответом.

Для начала нужно удалить страницу из навигации и поиска по сайту (на сайте больше не должно быть внутренних ссылок на эту товарную карточку). Далее проанализировать наличие переходов на товарные карточки. Если переходы есть и пользователей интересует именно эта модель, настраивать 301-й или 404-й будет неправильно. На таких карточках нужно предоставить информацию о том, что товара нет, и не будет в наличии, и предложить аналогичные товары, поместив блок «Вас также может заинтересовать».

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

Вопрос №3

Как поступить с ошибкой 404 для удалённых или несуществующих новостей. Оставить 404 или редиректить 301-м на главную?

Ответ

Вопрос №4

Как может сказаться на индексировании большое количество 301 редиректов на внутренние страницы? Есть сайт, каталог постоянно пополняется, но, одновременно, большая часть товара выбывает из оборота и больше поставляться не будет. На такие страницы ставится статус «под заказ», они отдают 200, пока ещё в индексе. Из них больше половины карточек товара, но фактически это мусор. Из-за опасения потерять трафик, есть предложение ставить на них 301 редирект. Как это скажется на индексировании?

Ответ

Если неправильно использовать, может сказаться негативно. Например, если со всех несуществующих страниц поставить 301-й редирект на одну страницу. Итог — поисковая система может или просто понизить в выдаче, или вовсе выкинуть весь старый контент из индекса вместе со ссылочной массой.

Такие страницы нужно удалить из навигации сайта, далее необходимо провести детальный анализ, описанный в статье «Как не терять трафик из товарных карточек, если товара нет в наличии?». По результату анализа настроить постраничный 301 редирект на аналогичные модели или настроить 404 ответ сервера.

Вопрос №5

Подскажите, а можно ли убрать 301 редирект. Например, товар снова появился в продаже через некоторое время, а до этого был отключён и через 301 редирект связан с материнским разделом.

Ответ

Если товар через некоторое время появился, можно убрать 301-й редирект. В таком случае нужно добавить восстановленные страницы на переобход в Яндекс.Вебмастер и Google Search Console.

Вопрос №6

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

Вариант 1. Просто снимаем материалы, пусть поиску отдаются 404 или 410 ответы. Со временем они уйдут из выдачи, но на дубликаты могут быть ссылки и т. д.

Вариант 2. Снимаем материалы и делаем 301 редиректы на главные копии на основном сайте.

Вариант 3. На всех дублях указать канонические адреса.

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

Ответ

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

Не нашли ответа на интересующий вопрос? Тогда задайте его в комментариях!

Оптимизирую сайты с 2009 года. Люблю сложные кейсы, которые оказались не по зубам специалистам с других компаний. Делаю очень подробные аудиты.

Пишу статьи-инструкции на блог SiteClinic по SEO-инструментам и аналитике.

Любимая цитата: Чтобы добиться успеха, надо искренне любить то, чем вы занимаетесь.

How does HTTP 302 work?

How does HTTP 302 work? I would like to know the internals

5 Answers 5

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

You mean how do browsers handle it? The server sends a 302 code along with a Location header, and the browser requests the new URI specified by the Location header instead.

And potentially other headers at the server’s discretion.

The browser normally takes this as a directive to automatically make a new, separate request for the other URI specified by the location header. The client (browser) isn’t forced to do this (it could, in theory, just display a message to the user, or do whatever else it wants), but that’s how HTTP clients usually behave.

Note that since the 302 is a temporary redirection, a well-behaved client will continue to use the old URL in the future, rather than going directly to the new one (301 is a permanent redirection).

10.3.3 302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Коды ответов сервера и ошибки. HTTP 200, 301, 404, 302, 500, 503, 550 и др.

Включаемые в ответ HTTP-сервера данные представляют собой код, указывающий на результат обработки запроса. Эти коды ответов HTTP состоят из трех цифр, разделенных на категории:

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

2xx Success (Успех)

Ответы такого типа уведомляют пользователей о принятии и успешной обработке запросов клиента. Зависимо от того, какой сейчас текущий статус сервера, он все равно может отправлять заголовки и основную часть сообщения. Другими словами, этот тип ответов сервера предполагает, что действие, о котором клиент делал запрос, без сложностей приняли в обработку.

200 OK Код состояния 200, наверное, является наиболее популярным, но в то же время очень неприметным в плане использования. Он указывает, что передача данных между сервером и пользователем подошла к завершению, и все прошло так, как должно. Когда этот код нужно использовать? Постоянно!

201 Created (Создан) В связи с успешным выполнением запроса создался новый ресурс. К примеру, благодаря запросу юзера сгенерирован такой ранее не существующий веб-ресурс, как новая страница. Исходной сервер настроен так, что обязан создать ресурс еще до отправки 201 кода. Если документ не может быть сгенерирован своевременно, сервер использует в качестве альтернативы код 202 (принят).

202 Accepted (Принят) Текущий запрос был передан в стадию обработки, но в силу объективных факторов является незавершенным. Запрос к серверу может быть не завершенным, это зависит от факта, успешно ли прошла обработка и не отклонили ли его.

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

203 Non-Authoritative Information (Недостоверная информация) Серверу удалось полностью обработать запрос, но передаваемые данные не были взяты из первостепенного источника (резервная копия, другой сервер и т. д.) и поэтому информация может быть нерелевантной. Этот код имеет большое сходство с 200 серверным ответом, но указывает, что данные не были получены из источника.

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

204 No Content (Нет контента) Этот код является ответом сервера, который указывает, что запрос получили и поняли. Но при этом не существует данных, которые могут быть отправлены пользователю. В основном такой код используется для активации скриптов без необходимости внесения изменений в веб-документ. Нужно, чтобы указанный код не содержал основного сообщения, и он должен быть вставлен в первую строку с кодом, которая является доступной сразу после заголовка.

Когда применяется такой код? Он используется в первую очередь, когда вы должны вводить или выполнять любые действия без необходимости в обновлении ресурса (например, страницы).

205 Reset Content (Сброс контента) Код обозначает успешную обработку запроса сервером c отсутствующим возвратом контента. В отличие от 204 кода, этот ответ требует, чтобы документ был обновлен.

Когда может применяться такой код? Обычно он используется в случаях, заполнения пользователем формы, и отправки сервером браузеру запроса на очистку этой формы. Он имеет сходство с 204 кодом, но выдвигает требование к пользователю по сбросу документа после завершения обработки. К примеру, требуется провести очистку HTML-формы после верификации.

206 Partial Reset (Частичный сброс) Сервер возвращает только часть контента, которая соответствует заголовку, отправленному клиентом. В основном его используют расширенные инструменты кэширования. Такое бывает, когда пользователь хочет получить лишь небольшую часть контента страницы, а сервер в своем ответе предоставляет данные только для этой части страницы.

Каковы способы применения этого кода? Преимущественно этот код используется из-за запроса If-Range, применимого в мощных кеш-валидаторах. Обращение также должно включать заголовки областей, которые используются в качестве параметров для области возвращаемой информации.

207 Multi-Status (Мультистатус) Сервер параллельно предоставляет результаты нескольких независимых операций, которые включаются в тело сообщения в виде XML-документа.