Купить веб-хостинг можно на нашем сайте.
Коды ответа веб-серверов — это трехзначные коды, которые посылаются сервером в ответ на запрос пользователя, для их дальнейшей обработки браузером.
Существует 5 диапазонов кодов состояния:
- Информационные 100-199 — означают, что запрос браузера принят и проходит обработку
- Успешные 200-299 — говорят о том, что запрос обработан и информация передана браузеру
- Перенаправление 300-399 — подразумевают собой, что браузер получает не то, что хотел пользователь
- Ошибка на стороне клиента 400-499
- Ошибка на стороне сервера 500-599.
Диапазон 100-199:
100 — Continue
Означает, что первая часть запроса была доставлена к серверу и он ожидает остальные.
101 — Switching Protocols
Означает, что сервер переключил протоколы.
102 — Processing
Означает, что идет обработка запроса и она займет много времени.
Диапазон 200-299:
200 — Ok
Сервер обработал запрос и передал информацию браузеру.
201 — Created
Сервер создал новый ресурс, после успешной обработки запроса.
202 — Accepted
Сервер принял запрос, но обрабатывать его будет позже. Это не гарантирует, что запрос в итоге будет обработан.
203 — Non-Authoritative Information
Сервер передал информацию, но взял он ее на другом сервере.
204 — No Content
Запрос был успешно обработан сервером, но в ответе на запрос имеются только заголовки без сообщения.
205 — Reset Content
Сервер сообщает пользователю о необходимости почистить, введенные им ранее, данные.
206 — Partial Content
Сервер принял запрос и вернул только часть запрошенных данных.
Диапазон 300-399:
300 — Multiple Choices
Код говорит о том, что у одного URL есть несколько вариантов доступа к ресурсу, по каким-либо факторам. Чаще всего проблема кроется в неправильно указанных заголовках, если указать их правильно проблема исчезнет.
301 — Moved Permanently
Пользователь запрашивает страницу, которая уже не поддерживается сервером. Сервер перенаправляет пользователя на другую страницу. Данный способ используется для редиректа.
302 — Moved Temporarily
Данный код похож на код 301, но отличается тем, что нужная страница временно недоступна. Например, на сайте ведутся работы и сервер перенаправляет пользователя на его дубликат, но с другим адресом.
303 — See Other
Код говорит о том, что запрошенная страница недоступна по запрашиваемому адресу, но доступна по другому, который можно найти по GET-запросу.
304 — Not Modified
Страница не изменялась с определенного времени и она может быть использована браузером. Ускоряет время загрузки страниц, которые не изменялись.
305 — Use Proxy
Доступ к странице может быть произведен только через прокси-сервер.
307 — Temporary Redirect
Запрашиваемый ресурс временно недоступен по старому URL, но доступен по другому URL. Менять метод запроса не разрешается.
Диапазон 400-499:
400 — Bad Request
Сервер не разобрал запрос пользователя из-за синтаксической ошибки.
401 — Unauthorized
Сообщает о том, что для доступа к информации нужно быть авторизованным.
402 — Payment Required
Предусмотрен для платных пользовательских сервисов и означает, что плата за услуги просрочена. Не касается хостинговых провайдеров.
403 — Forbidden
Ошибка сообщает о том, что доступ к данной странице запрещен или не может быть предоставлен сервером.
404 — Not Found
Страница которую хочет увидеть пользователь не найдена, так как удалена или ее адрес введен неверно.
405 — Method Not Allowed
Означает, что в запросе указан неподдерживаемый сервером метод.
406 — Not Acceptable
Пользователь пытается посмотреть страницу, которая есть на сервере, но имеет данные которые не поддерживаются у пользователя.
407 — Proxy Authentication Required
Сообщает о том, что для доступа к ресурсу необходима аутентификация прокси-сервера.
408 — Request Time-out
Пользователь не передал полные данные на сервер за определенное время. В итоге соединение было разорвано сервером.
409 — Conflict
Запросы, которые отсылает пользователь конфликтует с другим запросом или с самим сервером.
410 — Gone
Пользователь пытается посмотреть страницу, которая навсегда была удаленна с сервера.
411 — Length Required
Запрос требует заполнение поля Content-Length.
413 — Request Entity Too Large
Сервер не может обработать запрос, так как он очень большой.
414 — Request URL Too Long
Слишком длинный URL, поэтому сервер не может его обработать.
415 — Unsupported Media Type
Сервер не может обработать запрос из-за того, что формат запроса клиента не поддерживается сервером.
416 — Requested Range Not Satisfiable
Пока значение поля Range не станет корректным, сервер не сможет выполнить запрос.
417 — Expectation Failed
Данная ошибка возникает из-за того, что значение поля Expect являются некорректными.
422 — Unprocessable Entity
Какая-то часть запроса не обрабатывается сервером.
423 — Locked
Запрашиваемая страница была заблокирована.
424 — Failed Dependency
Доступ к странице не может быть предоставлен, так как один из ресурсов сервера недоступен или блокирован.
426 — Upgrade Required
Приняв запрос, сервер запрашивает SSL соединение, которое не поддерживается пользователем.
Диапазон 500-599:
500 Internal Server Error
На сервере произошла непредвиденная ошибка или аварийный отказ.
501 — Not Implemented
У сервера нет необходимых возможностей, для того чтобы обработать запрос.
502 — Bad Gateway
Запрос пользователя отправляется к серверу, но тот сопряжен еще с несколькими серверами, между которыми образуется цепочка. В одном из серверов цепочки может произойти сбой, и первый сервер выдает данную ошибку.
503 — Service Unavailable
Сервер временно перестал работать. Вместе с ошибкой может появиться параметр Retry-After, его значение показывает через какое время можно повторить попытку зайти на данный ресурс.
504 — Gateway Time-out
Сервер, который принял запрос находится в цепочке серверов. Так как сервер не получил ответ от вышестоящего сервера, возникает данная ошибка.
505 — HTTP Version not supported
Указанный в запросе протокол HTTP сервер не поддерживает или отказывается работать с данной версией протокола.
507 — Insufficient Storage
Сервер не может обработать запрос, потому что места на диске недостаточно.
510 — Not Extended
На сервере не поддерживается расширение, которое хочет использовать пользователь. Дополнительно сервер может передать пользователю информацию о доступных расширениях.
This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any 1xx status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions.
A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message. Unexpected 1xx status responses MAY be ignored by a user agent.
Proxies MUST forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself requested the generation of the 1xx response.
(For example, if a proxy adds a «Expect: 100-continue» field when it forwards a request, then it need not forward the corresponding 100 (Continue) responses).)
********************************************
1xx (Provisional response)
Status codes that indicate a provisional response and require the requester to take action to continue.
| Code | Description |
|---|---|
| 100 (Continue) | The requester should continue with the request. The server returns this code to indicate that it has received the first part of a request and is waiting for the rest. —————————————— The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. See section 8.2.3 for detailed discussion of the use and handling of this status code. |
| 101 (Switching protocols) | The requestor has asked the server to switch protocols and the server is acknowledging that it will do so. ————————————————— The server understands and is willing to comply with the client’s request, via the Upgrade message header field (section 14.42), for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response’s Upgrade header field immediately after the empty line which terminates the 101 response. The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features. |
Additional info:
The purpose of the 100 (Continue) status is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body.
Requirements for HTTP/1.1 clients:
— If a client will wait for a 100 (Continue) response before
sending the request body, it MUST send an Expect request-header
field (section 14.20) with the «100-continue» expectation.
— A client MUST NOT send an Expect request-header field (section
14.20) with the «100-continue» expectation if it does not intend
to send a request body.
Because of the presence of older implementations, the protocol allows ambiguous situations in which a client may send «Expect: 100- continue» without receiving either a 417 (Expectation Failed) status or a 100 (Continue) status. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the client SHOULD NOT wait for an indefinite period before sending the request body.
Requirements for HTTP/1.1 origin servers:
— Upon receiving a request which includes an Expect request-header
field with the «100-continue» expectation, an origin server MUST
either respond with 100 (Continue) status and continue to read
from the input stream, or respond with a final status code. The
origin server MUST NOT wait for the request body before sending
the 100 (Continue) response. If it responds with a final status
code, it MAY close the transport connection or it MAY continue
to read and discard the rest of the request. It MUST NOT
perform the requested method if it returns a final status code.
— An origin server SHOULD NOT send a 100 (Continue) response if
the request message does not include an Expect request-header
field with the «100-continue» expectation, and MUST NOT send a
100 (Continue) response if such a request comes from an HTTP/1.0
(or earlier) client. There is an exception to this rule: for
compatibility with RFC 2068, a server MAY send a 100 (Continue)
status in response to an HTTP/1.1 PUT or POST request that does
not include an Expect request-header field with the «100-
continue» expectation. This exception, the purpose of which is
to minimize any client processing delays associated with an
undeclared wait for 100 (Continue) status, applies only to
HTTP/1.1 requests, and not to requests with any other HTTP-
version value.
— An origin server MAY omit a 100 (Continue) response if it has
already received some or all of the request body for the
corresponding request.
— An origin server that sends a 100 (Continue) response MUST
ultimately send a final status code, once the request body is
received and processed, unless it terminates the transport
connection prematurely.
— If an origin server receives a request that does not include an
Expect request-header field with the «100-continue» expectation,
the request includes a request body, and the server responds
with a final status code before reading the entire request body
from the transport connection, then the server SHOULD NOT close
the transport connection until it has read the entire request,
or until the client closes the connection. Otherwise, the client
might not reliably receive the response message. However, this
requirement is not be construed as preventing a server from
defending itself against denial-of-service attacks, or from
badly broken client implementations.
Requirements for HTTP/1.1 proxies:
— If a proxy receives a request that includes an Expect request-
header field with the «100-continue» expectation, and the proxy
either knows that the next-hop server complies with HTTP/1.1 or
higher, or does not know the HTTP version of the next-hop
server, it MUST forward the request, including the Expect header
field.
— If the proxy knows that the version of the next-hop server is
HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
respond with a 417 (Expectation Failed) status.
— Proxies SHOULD maintain a cache recording the HTTP version
numbers received from recently-referenced next-hop servers.
— A proxy MUST NOT forward a 100 (Continue) response if the
request message was received from an HTTP/1.0 (or earlier)
client and did not include an Expect request-header field with
the «100-continue» expectation. This requirement overrides the
general rule for forwarding of 1xx responses
Resources:
W3.org
Уровень сложности
Простой
Время на прочтение
9 мин
Количество просмотров 28K
Привет! Меня зовут Ивасюта Алексей, я техлид команды Bricks в Авито в кластере Architecture. Я решил написать цикл статей об истории и развитии HTTP, рассмотреть каждую из его версий и проблемы, которые они решали и решают сейчас.
Весь современный веб построен на протоколе HTTP. Каждый сайт использует его для общения клиента с сервером. Между собой сервера тоже часто общаются по этому протоколу. На данный момент существует четыре его версии и все они до сих пор используются. Поэтому статьи будут полезны инженерам любых уровней и специализаций, и помогут систематизировать знания об этой важной технологии.
Что такое HTTP
HTTP — это гипертекстовый протокол передачи данных прикладного уровня в сетевой модели OSI. Его представил миру Тим Бернерс-Ли в марте 1991 года. Главная особенность HTTP — представление всех данных в нём в виде простого текста. Через HTTP разные узлы в сети общаются между собой. Модель клиент-серверного взаимодействия классическая: клиент посылает запрос серверу, сервер обрабатывает запрос и возвращает ответ клиенту. Полученный ответ клиент обрабатывает и решает: прекратить взаимодействие или продолжить отправлять запросы.
Ещё одна особенность: протокол не сохраняет состояние между запросами. Каждый запрос от клиента для сервера — отдельная транзакция. Когда поступают два соседних запроса, сервер не понимает, от одного и того же клиента они поступили, или от разных. Такой подход значительно упрощает построение архитектуры веб-серверов.
Как правило, передача данных по HTTP осуществляется через открытое TCP/IP-соединение1. Серверное программное обеспечение по умолчанию обычно использует TCP-порт 80 для работы веб-сервера, а порт 443 — для HTTPS-соединений.
HTTPS (HTTP Secure) — это надстройка над протоколом HTTP, которая поддерживает шифрование посредством криптографических протоколов SSL и TLS. Они шифруют отправляемые данные на клиенте и дешифруют их на сервере. Это защищает данные от чтения злоумышленниками, даже если им удастся их перехватить.
HTTP/0.9
В 1991 году была опубликована первая версия протокола с названием HTTP/0.9. Эта реализация была проста, как топор. От интернет-ресурса того времени требовалось только загружать запрашиваемую HTML-страницу и HTTP/0.9 справлялся с этой задачей. Обычный запрос к серверу выглядел так:
GET /http-spec.htmlВ протоколе был определен единственный метод GET и и указывался путь к ресурсу. Так пользователи получали страничку. После этого открытое соединение сразу закрывалось.
HTTP/1.0
Годы шли и интернет менялся. Стало понятно, что нужно не только получать странички от сервера, но и отправлять ему данные. В 1996 году вышла версия протокола 1.0.
Что изменилось:
-
В запросе теперь надо было указывать версию протокола. Так сервер мог понимать, как обрабатывать полученные данные.
-
В ответе от сервера появился статус завершения обработки запроса.
-
К запросу и ответу добавился новый блок с заголовками.
-
Добавили поддержку новых методов:
-
HEAD запрашивает ресурс так же, как и метод GET, но без тела ответа. Так можно получить только заголовки, без самого ресурса.
-
POST добавляет сущность к определённому ресурсу. Часто вызывает изменение состояния или побочные эффекты на сервере. Например, так можно отправить запрос на добавление нового поста в блог.
Структура запроса
Простой пример запроса:
GET /path HTTP/1.0
Content-Type: text/html; charset=utf-8
Content-Length: 4
X-Custom-Header: value
testВ первой строчке указаны метод запроса — GET, путь к ресурсу — /path и версия протокола — HTTP/1.0.
Далее идёт блок заголовков. Заголовки — это пары ключ: значение, каждая из которых записывается с новой строки и разделяется двоеточием. Они передают дополнительные данные и настройки от клиента к серверу и обратно.
HTTP — это текстовый протокол, поэтому и все данные передаются в виде текста. Заголовки можно отделить друг от друга только переносом строки. Нельзя использовать запятые, точку с запятой, или другие разделители. Всё, что идет после имени заголовка с двоеточием и до переноса строки, будет считаться значением заголовка2.
В примере серверу передали три заголовка:
-
Content-Type— стандартный заголовок. Показывает, в каком формате будут передаваться данные в теле запроса или ответа. -
Content-Length— сообщает длину контента в теле запроса в байтах. -
X-Custom-Header— пользовательские заголовки, начинающиеся сX-с произвольными именем. Через них реализуется специфическая логика обработки для конкретного сервера. Если веб-сервер не поддерживает такие заголовки, то он проигнорирует их.
После блока заголовков идёт тело запроса, в котором передается текст test.
А так может выглядеть ответ от сервера:
HTTP/1.1 200 OK
Date: Thu, 29 Jul 2021 19:20:01 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 2
Connection: close
Server: gunicorn/19.9.0
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
OKВ первой строке — версия протокола и статус ответа, например, 200 ОК. Далее идут заголовки ответа. После блока заголовков — тело ответа, в котором записан текст OK.
Статусы ответов
Клиенту зачастую недостаточно просто отправить запрос на сервер. Во многих случаях надо дождаться ответа и понять, как сервер обработал запрос. Для этого были придуманы статусы ответов. Это трёхзначные числовые коды с небольшими текстовыми обозначениями. Их можно увидеть в терминале или браузере. Сами коды делятся на 5 классов:
-
Информационные ответы: коды 100–199
-
Успешные ответы: коды 200–299
-
Редиректы: коды 300–399
-
Клиентские ошибки: коды 400–499
-
Серверные ошибки: коды 500–599
Мы рассмотрим основные коды, которые чаще всего встречаются в реальных задачах. С остальными более подробно можно ознакомиться в реестре кодов состояния HTTP.
Информационные ответы
100 Continue — промежуточный ответ. Он указывает, что запрос успешно принят. Клиент может продолжать присылать запросы или проигнорировать этот ответ, если запрос был завершён.
Примечание
Этот код ответа доступен с версии HTTP/1.1.
101 Switching Protocol присылается в ответ на запрос, в котором есть заголовок Upgrade. Это означает, что сервер переключился на протокол, который был указан в заголовке. Такая методика используется, например, для переключения на протокол Websocket.
102 Processing — запрос получен сервером, но его обработка ещё не завершена.
Успешные ответы
200 OK — запрос принят и корректно обработан веб-сервером.
201 Created — запрос корректно обработан и в результате был создан новый ресурс. Обычно он присылается в ответ на POST запрос.
Редиректы
301 Moved Permanently — запрашиваемый ресурс на постоянной основе переехал на новый адрес. Тогда новый путь к ресурсу указывается сервером в заголовке Location ответа.
Примечание
Клиент может изменить метод последующего запроса с POST на GET.
302 Found — указывает, что целевой ресурс временно доступен по другому URl. Адрес перенаправления может быть изменен в любое время, а клиент должен продолжать использовать действующий URI для будущих запросов. Тогда временный путь к ресурсу указывается сервером в заголовке Location ответа.
Примечание
Клиент может изменить метод последующего запроса с POST на GET.
307 Temporary Redirect — имеет то же значение, что и код 302, за исключением того, что клиент не может менять метод последующего запроса.
308 Permanent Redirect — имеет то же значение, что и код 301, за исключением того, что клиент не может менять метод последующего запроса.
Клиентские ошибки
400 Bad Request — запрос от клиента к веб-серверу составлен некорректно. Обычно это происходит, если клиент не передаёт необходимые заголовки или параметры.
401 Unauthorized — получение запрашиваемого ресурса доступно только аутентифицированным пользователям.
403 Forbidden — у клиента не хватает прав для получения запрашиваемого ресурса. Например, когда обычный пользователь сайта пытается получить доступ к панели администратора.
404 Not Found — сервер не смог найти запрашиваемый ресурс.
405 Method Not Allowed — сервер знает о существовании HTTP-метода, который был указан в запросе, но не поддерживает его. В таком случае сервер должен вернуть список поддерживаемых методов в заголовке Allow ответа.
Серверные ошибки
500 Internal Server Error — на сервере произошла непредвиденная ошибка.
501 Not Implemented — метод запроса не поддерживается сервером и не может быть обработан.
502 Bad Gateway — сервер, действуя как шлюз или прокси, получил недопустимый ответ от входящего сервера, к которому он обращался при попытке выполнить запрос.
503 Service Unavailable — сервер не готов обработать запрос (например, из-за технического обслуживания или перегрузки). Обратите внимание, что вместе с этим ответом должна быть отправлена удобная страница с объяснением проблемы. Этот ответ следует использовать для временных условий, а HTTP-заголовок Retry-After по возможности должен содержать расчётное время до восстановления службы.
504 Gateway Timeout — этот ответ об ошибке выдается, когда сервер действует как шлюз и не может получить ответ за отведенное время.
505 HTTP Version Not Supported — версия HTTP, используемая в запросе, не поддерживается сервером.
В HTTP из всего диапазона кодов используется совсем немного. Те коды, которые не используются для задания определенной логики в спецификации, являются неназначенными и могут использоваться веб-серверами для определения своей специфической логики. Это значит, что вы можете, например, придать коду 513 значение «Произошла ошибка обработки видео», или любое другое. Неназначенные коды вы можете посмотреть в реестре кодов состояния HTTP.3
Тело запроса и ответа
Тело запроса опционально и всегда отделяется от заголовков пустой строкой. А как понять, где оно заканчивается? Всё кажется очевидным: где кончается строка, там и заканчивается тело. Однако, два символа переноса строки в HTTP означают конец запроса и отправляют его на сервер. Как быть, если мы хотим передать в теле текст, в котором есть несколько абзацев с разрывами в две строки?
POST /path HTTP/1.1
Host: localhost
Первая строка
Вторая строка после разрываПо логике работы HTTP соединение отправится сразу после второй пустой строки и сервер получит в качестве данных только строку Первая строка. Описанную проблему решает специальный заголовок Content-Length. Он указывает на длину контента в байтах. Обычно клиенты (например, браузеры) автоматически считают длину передаваемых данных и добавляют к запросу заголовок с этим значением. Когда сервер получит запрос, он будет ожидать в качестве контента ровно столько байт, сколько указано в заголовке.
Однако, этого недостаточно для того, чтобы передать данные на сервер. Поведение зависит от реализации сервера, но для большинства из них необходимо также передать заголовок Content-Type. Он указывает на тип передаваемых данных. В качестве значения для этого заголовка используют MIME-типы.4
MIME (Multipurpose Internet Mail Extensions, многоцелевые расширения интернет-почты) — стандарт, который является частью протокола HTTP. Задача MIME — идентифицировать тип содержимого документа по его заголовку. К примеру, текстовый файл имеет тип text/plain, а HTML-файл — text/html.
Для передачи данных в формате обычного текста надо указать заголовок Content-Type: text/plain, а для JSON — Content-Type: application/json.
Можно ли передать тело с GET-запросом?
Популярный вопрос на некоторых собеседованиях: «Можно ли передать тело с GET-запросом?». Правильный ответ — да. Тело запроса не зависит от метода. В стандарте не описана возможность принимать тело запроса у GET-метода, но это и не запрещено. Технически вы можете отправить данные в теле, но скорее всего веб-сервер будет их игнорировать.
Представим, что на абстрактном сайте есть форма аутентификации пользователя, в которой есть всего два поля: email и пароль.
Если пользователь ввёл данные и нажал на кнопку «Войти», то данные из полей формы должны попасть на сервер. Самым простым и распространенным форматом передачи таких данных будет MIME application/x-www-form-urlencoded. В нем все поля передаются в одной строке в формате ключ=значение и разделяются знаком &.
Запрос на отправку данных будет выглядеть так:
POST /login HTTP/1.0
Host: example.com
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 26
login=user&password=qwertyТут есть небольшая особенность. Как понять, где заканчивается ключ и начинается его значение, если в пароле будет присутствовать знак «=» ?
POST /login HTTP/1.0
Host: example.com
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 26
login=user&password=123=45В этом случае сервер не сможет понять, как разбить строку на параметры и их значения. На самом деле значения кодируются при помощи механизма url encoding.5 При использовании этого механизма знак «=» будет преобразован в код %3D .
Тогда наш запрос приобретёт такой вид:
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 28
login=user&password=123%3D45Query string
Данные на сервер можно передавать через тело запроса и через так называемую строку запроса Query String. Это параметры формата ключ=значение, которые располагаются в пути к ресурсу:
GET /files?key=value&key2=value2 HTTP/1.0При этом параметры можно передавать прямо от корня домена:
GET /?key=value&key2=value2 HTTP/1.0Query String имеет такой же формат, как и тело запроса с MIME application/x-www-form-urlencoded, только первая пара значений отделяется от адреса вопросительным знаком.
Некоторые инженеры ошибочно полагают, что Query String являются параметрами GET-запроса и даже называют их GET-параметрами, но на самом деле это не так. Как и тело запроса, Query String не имеет привязки к HTTP-методам и может передаваться с любым типом запросов.
Обычно параметры Query String используются в GET-запросах, чтобы конкретизировать получаемый ресурс. Например, можно получить на сервере список файлов, имена которых будут начинаться с переданного значения.
GET-запросы по своей идеологии должны быть идемпотентными. Это значит, что множественный вызов метода с одними и теми же параметрами должен приводить к одному и тому же результату. Например, поисковые боты перемещаются по сайту только по ссылкам и делают только GET-запросы, потому что исходя из семантики они не смогут таким образом изменить данные на сайте и повлиять на его работу.
На этом я закончу говорить про версию протокола 1.0, структуру ответов и запросов. В следующей статье я расскажу, что такое Cookies, для чего нужен CORS и как это всё работает. А пока напоследок оставлю полезные ссылки, которые упомянул в тексте:
-
Основы TCP/IP
-
Заголовки HTTP
-
Реестр кодов состояния HTTP
-
MIME типы
-
Алгоритм кодирования URL encoding
Следующая статья: Ультимативный гайд по HTTP. Cookies и CORS
Коды ответа сервера — это средство для общения между сервером и клиентом, которое сообщает о результате запроса на сервере. Коды ответа сервера являются трехзначными числами, которые отправляются вместе с заголовками HTTP-ответа. Коды ответа сервера позволяют клиентам понимать, произошла ли ошибка во время запроса или же запрос был выполнен успешно.
Коды ответа сервера делятся на несколько групп. Некоторые из них сообщают об успешном выполнении запроса, другие сообщают об ошибках, а некоторые сообщают о перенаправлении.
Группы кодов ответа сервера
Коды ответа сервера делятся на пять групп:
- Информационные коды ответа (100-199)
- Успешные коды ответа (200-299)
- Коды перенаправления (300-399)
- Коды ошибок клиента (400-499)
- Коды ошибок сервера (500-599)
Каждая группа кодов ответа сервера имеет свойственную себе цифру в первой позиции. Первый разряд определяет группу, а оставшиеся два разряда определяют конкретный код ответа.
Информационные коды ответа (100-199)
Информационные коды ответа сообщают клиенту, что сервер принял запрос и продолжает обработку. Обычно, информационные коды ответа используются во время передачи больших объемов данных, чтобы сообщить клиенту о текущем статусе процесса. Клиент обычно не использует эти коды ответа, так как они не сообщают о результатах выполнения запроса.
Примеры информационных кодов ответа сервера:
- 100 Continue — Этот код ответа сообщает клиенту, что сервер продолжает обработку запроса и ожидает дальнейшей информации от клиента.
- 101 Switching Protocols — Этот код ответа сообщает клиенту, что сервер переключается на другой протокол, например, при переходе с HTTP на WebSocket.
Успешные коды ответа (200-299)
Успешные коды ответа сообщают клиенту, что сервер успешно обработал запрос. Эти коды ответа сообщают о том, что клиент получил запрошенные данные, выполнился запрошенный действие или что сервер подтвердил отправку данных клиенту.
Примеры успешных кодов ответа сервера:
- 200 OK — Этот код ответа сообщает клиенту, что сервер успешно обработал запрос и вернул запрошенные данные.
- 201 Created — Этот код ответа сообщает клиенту, что сервер успешно создал ресурс по указанному URI (Uniform Resource Identifier) и вернул информацию о созданном ресурсе. Например, при создании новой записи в базе данных сервер может вернуть код ответа 201 и URI созданной записи в теле ответа.
- 204 No Content — Этот код ответа сообщает клиенту, что сервер успешно обработал запрос, но в ответе не содержится тела сообщения. Например, при удалении ресурса сервер может вернуть код ответа 204 без тела ответа.
Коды перенаправления (300-399)
Коды перенаправления используются для перенаправления клиента на другой ресурс. Эти коды ответа сообщают клиенту, что запрошенный ресурс был перемещен на другой URI, и клиент должен выполнить новый запрос для получения ресурса.
Примеры кодов перенаправления:
- 301 Moved Permanently — Этот код ответа сообщает клиенту, что запрошенный ресурс был перемещен на новый URI, и клиент должен использовать новый URI для дальнейшей работы с ресурсом. Читать подробнее — что такое 301 редирект.
- 302 Found — Этот код ответа сообщает клиенту, что запрошенный ресурс был временно перемещен на другой URI, и клиент должен использовать новый URI для дальнейшей работы с ресурсом. Однако, в отличие от кода ответа 301, клиент должен продолжать использовать старый URI в будущем.
Коды ошибок клиента (400-499)
Коды ошибок клиента сообщают клиенту, что сервер не смог обработать запрос из-за ошибок в запросе. Эти коды ответа сообщают о том, что клиент отправил некорректный запрос или запрос, который сервер не может обработать.
Примеры кодов ошибок клиента:
- 400 Bad Request — Этот код ответа сообщает клиенту, что сервер не может обработать запрос из-за некорректного синтаксиса запроса или неверных параметров.
- 403 Forbidden — Этот код ответа сообщает клиенту, что сервер понимает запрос, но отказывается выполнять его из-за отсутствия прав доступа у клиента.
Коды ошибок сервера (500-599)
Коды ошибок сервера сообщают клиенту, что сервер не смог обработать запрос из-за внутренней ошибки сервера. Эти коды ответа сообщают о том, что сервер не может выполнить запрос из-за ошибок на стороне сервера.
Примеры кодов ошибок сервера:
- 500 Internal Server Error — Этот код ответа сообщает клиенту, что сервер не смог выполнить запрос из-за внутренней ошибки сервера.
- 503 Service Unavailable — Этот код ответа сообщает клиенту, что сервер временно не может обработать запрос из-за перегрузки или неполадок в работе сервера. Клиент может повторить запрос позже.
Пример использования кодов ответа сервера
Давайте рассмотрим пример использования кодов ответа сервера на практике. Предположим, что у нас есть RESTful API для управления списком задач. Клиент отправляет запросы на создание, чтение, обновление и удаление задач, используя HTTP-методы POST, GET, PUT и DELETE соответственно.
При создании новой задачи сервер должен вернуть код ответа 201 и URI созданной задачи в теле ответа:
POST /api/tasks HTTP/1.1
Host: example.com
Content-Type: application/json
{
"title": "Написать текст на тему коды ответа сервера",
"description": "Написать уникальный, структурированный и продающий текст на тему коды ответа сервера.",
"due_date": "2023-04-01"
}
HTTP/1.1 201 Created
Location: /api/tasks/123
Content-Type: application/json
{
"id": 123,
"title": "Написать текст на тему коды ответа сервера",
"description": "Написать уникальный, структурированный и продающий текст на тему коды ответа сервера.",
"due_date": "2023-04-01",
"status": "в процессе"
}
При чтении задачи сервер должен вернуть код ответа 200 и тело ответа с информацией о задаче:
GET /api/tasks/123 HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-Type: application/json
{
"id": 123,
"title": "Написать текст на тему коды ответа сервера",
"description": "Написать уникальный, структурированный и продающий текст на тему коды ответа сервера.",
"due_date": "2023-04-01",
"status": "в процессе"
}
При обновлении задачи сервер должен вернуть код ответа 200 и тело ответа с обновленной информацией о задаче:
PUT /api/tasks/123 HTTP/1.1
Host: example.com
Content-Type: application/json
{
"title": "Написать уникальный текст на тему коды ответа сервера",
"description": "Написать уникальный, структурированный и продающий текст на тему коды ответа сервера.",
"due_date": "2023-04-01",
"status": "завершено"
}
HTTP/1.1 200 OK
Content-Type: application/json
{
"id": 123,
"title": "Написать уникальный текст на тему коды ответа сервера",
"
Вместо заключения
Хотите выйти в ТОП10 Яндекс и долго там оставаться? Продвигайте свои сайты и интернет-магазины исключительно белыми SEO методами! Не умеете? Могу научить! Тем, кто хочет разобраться во всех премудростях SEO, предлагаю посетить мои курсы по SEO обучению, которые я провожу индивидуально, в режиме онлайн по скайпу.
Для тех, у кого нет времени проходить обучение и самостоятельно заниматься продвижением своих интернет-магазинов, предлагаю и в этом вопросе помощь. Я могу взять ваш сайт на SEO продвижение и за несколько месяцев вывести его в ТОП10 Яндекс.
Для того чтобы убедиться в моей экспертности, предлагаю ознакомиться с моими последними SEO кейсами и только после этого заказать у меня SEO продвижение. Ниже на видео один из примеров успешного продвижения строительного сайта в Санкт-Петербурге.
Содержание
- 1 Коды ответов HTTP сервера
- 1.1 Информационные ответы
- 1.2 Успешные запросы клиента
- 1.3 Переадресация
- 1.4 Неполные запросы клиента
- 1.5 Ошибки сервера
Коды ответов HTTP сервера
rfc2616
В первой строке ответа HTTP-сервера содержится информация о том, был запрос клиента успешным или нет, а также данные о причинах успешного либо неуспешного завершения запроса. Эта информация обозначается трехразрядным кодом ответа сервера (иногда его называют кодом состояния) и сопровождается описательным сообщением.
Коды состояний обычно генерируются Web-серверами, но иногда это могут делать и CGI-сценарии, CGI-сценарии генерируют собственные заголовки вместо тех, которые должен выдавать сервер.
Коды состояний группируются следующим образом:
| Диапазон кодов | Значение ответа | |
| 100-199 | Информационный | |
| 200-299 | Запрос клиента успешен | |
| 300-399 | Запрос клиента переадресован, необходимы дальнейшие действия | |
| 400-499 | Запрос клиента является неполным | |
| 500-599 | Ошибки сервера |
В HTTP в каждом диапазоне определены лишь несколько кодов, хотя для сервера при необходимости могут определяться собственные коды. Клиент при получении кода, который он не может распознать, интерпретирует его в соответствии с диапазоном, к которому этот код принадлежит. Коды в диапазонах 100-199, 200-299 и 300-399 большинство Web-броузеров обрабатывают без извещения пользователя, а некоторые коды ошибок из диапазонов 400-499 и 500-599 отображаются для пользователя (например, 404 Not Found).
Информационные ответы
Ответы в диапазоне 100-199 — информационные; они показывают, что запрос клиента принят и обрабатывается.
| 100 | Continue | Начальная часть запроса принята, и клиент может продолжать передачу запроса. | |
| 101 | Switching Protocols | Сервер выполняет требование клиента и переключает протоколы в соответствии с указанием, данным в поле заголовка Upgrade. |
Успешные запросы клиента
Ответы в диапазоне 200-299 означают, что запрос клиента обработан успешно.
| 200 | OK | Запрос клиента обработан успешно, и ответ сервера содержит затребованные данные. | |
| 201 | Created | Этот код состояния используется в случае создания нового URI. Вместе с этим кодом результата сервер выдает заголовок Location, который содержит информацию о том, куда были помещены новые данные. | |
| 202 | Accepted | Запрос принят, но обрабатывается не сразу. В теле содержимого ответа сервера может быть дана дополнительная информация о данной транзакции. Гарантии того, что сервер в конечном итоге удовлетворит допустимым. | |
| 203 | Non-Authoritative Information | Информация в заголовке содержимого взята из локальной копии или у третьей стороны, а не с исходного сервера. | |
| 204 | No Content | Ответ содержит код состояния и заголовок, но тело содержимого отсутствует. При получении этого ответа броузер не должен обновлять свой документ. Обработчик чувствительных областей изображений может возвращать этот код, когда пользователь щелкает на бесполезных или пустых участках изображения. | |
| 205 | Reset Content | Броузер должен очистить форму, используемую в данной транзакции, для дополнительных входных данных. Полезен для CGI-приложений, требующих ввода данных. | |
| 206 | Partial Content | Сервер возвращает лишь часть данных затребованного объема. Используется в ответе на запрос с указанием заголовка Range. Сервер должен указать диапазон, включенный в ответ, в заголовке Content-Range. |
Переадресация
Код ответа в диапазоне 300-399 означает, что запрос не выполнен и клиенту нужно предпринять некоторые действия для удовлетворения запроса.
| 300 | Multiple Choices | Затребованный URI обозначает более одного ресурса. Например, URI может обозначать документ, переведенный на несколько языков. В теле содержимого, возвращенном сервером, может находиться перечень более конкретных данных о том, как выбрать ресурс правильно. | |
| 301 | Moved Permanently | Затребованный URI уже не используется сервером, и указанная в запросе операция не выполнена. Новое местонахождение затребованного документа указывается в заголовке Location. Во всех последующих запросах данного документа следует указывать новый URI. | |
| 302 | Moved Temporarily | Затребованный URI перемешен, но лишь временно. Заголовок Location указывает на новое местонахождение. Сразу же после получения этого кода состояния клиент должен разрешить запрос при помощи нового URI, но во всех последующих запросах необходимо пользоваться старым URI. | |
| 303 | See Other | Затребованный URI можно найти по другому URI (указанному в заголовке Location). Его следует выбрать методом GET по данному ресурсу. | |
| 304 | Not Modified | Это код ответа на заголовок lf-Modified-Since, если URI не изменялся с указанной даты. Тело содержимого не посылается, и клиент должен использовать свою локальную копию. | |
| 305 | Use Proxy | Доступ к затребованному URI должен осуществляться через proxy-сервер, указанный в заголовке Location. |
Неполные запросы клиента
Коды ответов в диапазоне 400-499 означают, что запрос клиента неполный. Эти коды могут также означать, что от клиента требуется дополнительная информация.
| 400 | Bad Request | Означает, что сервер обнаружил в запросе клиента синтаксическую ошибку. | |
| 401 | Unauthorized | Этот код результата, передаваемый с заголовком WWW-Authenticate, показывает, что пославший запрос пользователь не имеет необходимых полномочий и что при повторении запроса с указанием данного URI пользователь должен такие полномочия предоставить. | |
| 402 | Payment Required | Этот код в HTTP еще не реализован. | |
| 403 | Forbidden | Запрос отклонен по той причине, что сервер не хочет (или не имеет возможности) ответить клиенту. | |
| 404 | Not Found | Документ по указанному URI не существует. | |
| 405 | Method Not Allowed | Этот код выдается с заголовком Allow и показывает, что метод, используемый клиентом, для данного URI не поддерживается. | |
| 406 | Not Acceptable | Ресурс, указанный клиентом по данному URI, существует, но не в том формате, который нужен клиенту. Вместе с этим кодом сервер выдает заголовки Content-Language, Content-Encoding и Content-Type. | |
| 407 | Proxy Authentication Required | Proxy-сервер должен санкционировать запрос перед тем, как пересылать его. Используется с заголовком Proxy-Authenticate. | |
| 408 | Request Time-out | Этот код ответа означает, что клиент не передал полный запрос в течение некоторого установленного промежутка времени (который обычно задается в конфигурации сервера) и сервер разрывает сетевое соединение. | |
| 409 | Conflict | Данный запрос конфликтует с другим запросом или с конфигурацией сервера. Информацию о конфликте следует возвратить в информационной части ответа. | |
| 410 | Gone | Данный код показывает, что затребованный URI больше не существует и навсегда удален с сервера. | |
| 411 | Length Required | Сервер не примет запрос без указанного в нем заголовка Content-Length. | |
| 412 | Precondition Failed | Результат вычисления условия, заданного в запросе одним или несколькими заголовками if. . ., представляет собой «ложь». | |
| 413 | Request Entity Too Large | Сервер не будет обрабатывать запрос, потому что его тело слишком велико. | |
| 414 | Request-URI Too Long | Сервер не будет обрабатывать запрос, потому что его URI слишком длинный. | |
| 415 | Unsupported Media Type | Сервер не будет обрабатывать запрос, потому что его тело имеет неподдерживаемый формат. |
Ошибки сервера
Коды ответов в диапазоне 500-599 показывают, что сервер столкнулся с ошибкой и, вероятно, не сможет выполнить запрос клиента.
| 500 | Internal Server Error | При обработке запроса на сервере один из его компонентов (например, CGI-программа) выдал аварийный отказ или столкнулся с ошибкой конфигурации. | |
| 501 | Not Implemented | Клиент запросил выполнение действия, которое сервер выполнить не может. | |
| 502 | Bad Gateway | Сервер (или proxy-сервер) получил недопустимые ответы другого сервера (или proxy-сервера). | |
| 503 | Service Unavailable | Данный код означает, что данная служба временно недоступна, но в будущем доступ к ней будет восстановлен. Если сервер знает, когда это произойдет, может быть также выдан заголовок Retry-After. | |
| 504 | Gateway Time-out | Этот ответ похож на 408 (Request Time-out) , за исключением того, что шлюз или уполномоченный сервер превысил лимит времени. | |
| 505 | HTTP Version not supported | Сервер не поддерживает версию протокола HTTP, использованную в запросе. |