Каждый успешный HTTP-запрос всегда возвращает код состояния 200?

в Delphi я использую Indy's TIdHTTPWebBrokerBridge в сочетании с TIdHTTP для отправки / получения данных через HTTP. На сервере у меня нет никакой причудливой обработки, я всегда просто отвечаю простым потоком контента. Если есть какие-либо проблемы, я возвращаю только информацию об этой проблеме в содержимом ответа (например, ошибка аутентификации, недопустимый запрос и т. д.). Таким образом, на стороне клиента, я могу предположить, что каждый успешный запрос я делаю на этот сервер всегда будет иметь код ответа 200 (Хорошо)?

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

внутри этой функции:

IdHTTP.Get(SomeURL, AStream);
Result:= IdHTTP.ResponseCode = 200;

эта функция обрабатывает любой запрос, который может получать данные. Если в запросе были какие-либо проблемы, эта функция должна возвращать False. В моем сценарии, поскольку я всегда возвращаю какой-то контент на сервере, клиент всегда будет получать ответ код 200 в этой функции?

Я думаю, реальный вопрос в том, если я всегда возвращаю какой-то контент и обрабатываю все исключения на сервере, то сервер всегда будет возвращать код состояния 200 для каждого запроса?

11
delphi http http-status-codes indy

4 ответов

чтобы ответить на ваш конкретный вопрос:

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

ответ да, потому что TIdHTTPWebBrokerBridge обертывания TIdHTTPServer, который всегда устанавливает код ответа по умолчанию 200 для каждого запроса, если вы сами не перезаписываете его другим значением или не заставляете ваш сервер делать что-то, что неявно отвечает другой код ответа (например,Redirect() который использует 302, или SmartServeFile(), который использует 304), или столкнуться с ошибкой, которая вызывает TIdHTTPServer чтобы назначить код ответа на ошибку 4xx или 5xx.

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

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

если есть конкретный код ответа, который обычно вызывает исключение, но вы не хотите, вы можете указать это значение в параметр на TIdHTTP.Get() или TIdHTTP.DoRequest(). Или, если вы используете обновленный Indy 10 SVN редакция, Новая hoNoProtocolErrorException флаг был недавно добавлен в TIdHTTP.HTTPOptions свойство так что EIdHTTPProtocolException исключение не вызывается для любого кода ответа.

9

" каждый успешный HTTP-запрос всегда возвращает код состояния 200?"

посмотреть w3.org: HTTP/1.1 Status Code Definitions (RFC 2616)

ответ нет. Все 2xx считаются успешными. Это может зависеть от метод HTTP используется.

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

на PUT метод (выделено мной):

если существующий ресурс модифицирован, либо 200 (OK) или 204 (нет Содержание) коды ответов должны быть отправлено для указания успешного завершение запроса.

на POST способ:

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

если ресурс был создан на исходном сервере, в ответ должны быть 201 (созданные) и содержит сущность, которая описывает статус запроса и относится к новому ресурс и местоположение заголовок (см. раздел 14.30). Ответы на этот метод не cacheable, если ответ не включает соответствующий контроль кэша или Истекает полей заголовка. Однако 303 (см. другой) ответ может быть используется для направления агента пользователя на получение кэшируемого ресурса.

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

Ваш вопрос:

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

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

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

17

удачный resposes являются 2хх List_of_HTTP_status_codes

2

Я сделал следующее. Обрабатывайте все 200-е и регистрируйте исключения. работал, не один не 200-кроме несанкционированных и тайм-аутов (пароль или иногда недоступный сервер). но многие/все ответы будут рассмотрены различные популярные приложения.

      while (iRedo < 3) do begin
        s := Self.HTTPComponent.Get( sUrl );

        if self.HTTPComponent.ResponseCode = 200 then begin
          break;
        end;

        // IDEIA - log what happend if not 200
        logWhatHappend( s, HTTPComponent ); // then log content, headers, etc
        inc( iRedo ); sleep( 5 );
      end;
1