Ответ HTTP "200 OK" дает гарантию того, что документ был получен машиной, которая сгенерировала HTTP-запрос?

Ответ 1

Код HTTP 200 также работает как подтверждение того, что документ был получен?

Нет. Совсем нет.

Это даже не гарантия того, что документ был полностью передан.

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

На самом деле, нет никакого способа, чтобы сервер мог узнать, получил ли клиент полный (или частичный) HTTP-ответ. В протоколе HTTP не предусмотрено подтверждение.

Теперь вы можете реализовать протокол приложения поверх HTTP, в котором клиент должен отправить второй HTTP-запрос на сервер, чтобы сказать "да, я получил документ". Но это потребует некоторой "логики приложения", реализованной в пользовательском браузере; например, в Javascript.

Ответ 2

Точно нет. HTTP 200 генерируется сервером и только означает, что он понимает запрос и считает, что он способен его выполнить (например, файл на самом деле там). Во время передачи полного документа ответа (разрыва сетевого соединения, потери пакетов и т.д.) Могут возникать всевозможные ошибки, которые не будут отображаться в ответе HTTP, но их необходимо обнаруживать отдельно.

Ответ 3

Хорошее руководство по протоколу HTTP можно найти здесь: http://blog.catchpoint.com/2010/09/17/anatomyhttp/

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

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

Однако, поскольку транспорт потока является надежным, акт отправки ответа будет либо успешным, либо приведет к ошибке. Это проверяет, был ли документ получен сетевой сетью (как указано TripeHound, в случае непрямого подключения, например прокси, это не гарантия доставки конечной цели).

Ответ 4

Очень просто заметить, что код ответа 200 OK не может быть гарантией чего-либо в документе ответа. Он отправляется до передачи документа, поэтому только нарушение причинности может позволить ему зависеть от успешного приема документа. Он служит только индикатором того, что запрос был получен правильно, и сервер считает, что он способен выполнить запрос. Если для запроса требуется дополнительная обработка (например, запуск сценария), а не просто возврат статического документа, код ответа обычно должен быть отправлен после того, как это было завершено, поэтому обычно это индикатор того, что это было успешным (но бывают ситуации, когда это не представляется возможным, например, запросы с постоянными соединениями и push-уведомлениями - сценарий может завершиться неудачей позже).

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

Ответ 5

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

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

Ответ 6

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

После того, как запрос достигнет B, и нет ошибок, сбивающих B, и никакого аппаратного сбоя и т.д. B будет проверять запрос и определять, что делать и какой статус сообщать. Если A запросил файл, который есть, и A разрешен доступ, B начнет отправлять "статус 200" вместе с файловыми данными.

Снова всевозможные вещи могут пойти не так. A может не получить ничего или "статус 200" без данных или неполных данных и т.д. ("Принимать" я имею в виду, что данные поступают на кабель Ethernet или через WiFi).

Обычно пользователь A будет использовать некоторую библиотеку, которая обрабатывает уродливые биты. С некоторой приличной библиотекой пользователь может ожидать, что они либо получат некоторую ошибку, либо статус, соответствующий соответствующим данным. Если статус 200 поступает на A с половиной данных, пользователь (в зависимости от дизайна библиотеки) получит ошибку, а не статус и определенно не статус 200.

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

Но в общем случае случай, когда пользователь получает статус 200, и данных не будет.