LINUX.ORG.RU

200 OK HTTP/1.0-1.1

 , , ,


0

1

Читаю спеки и никак не вычитаю нужное.

Мой вопрос выглядит так:

При каких условиях я должен отправить «HTTP/1.0 200 OK», а при каких «HTTP/1.1 200 OK»?

Например, если клиент обратился с HTTP/1.0 то и я должен ответить ему с той же версией протокола? Могули я поднять версию в ответе до 1.1?

А если клиент обратился с HTTP/1.1, могу ли я задаунгрейдить ответ до 1.0 или обязательно должен подстроиться под версию запроса клиента?

Что делать если клиент обращается как 1.0, но шлёт с этим методы и заголовки которые можно только в 1.1? Ответить ему бэд реквестом?

★★★★★

Последнее исправление: deep-purple (всего исправлений: 1)

я бы отвечал на ту версию которую просит клиент принимал или посылал бы его нафиг

а он бы уже сам думал как ему переподключится с другой версией

anonymous
()

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

anonymous
()
Ответ на: комментарий от anonymous

Клиенты — чаще железки и реже ПО. Если с ПО еще теоретически можно что-то сделать, то с железками — нет. А квалификация операторов тех железок/ПО заканчивается на «прочитать инструкцию и попробовать вбить настройки у себя». Поэтому хочется закрыть вопрос спецификации по обмену данными, реализовав у себя всё по спекам и в случае чего тыкать носом уже производителей железок и авторов ПО.

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от anonymous

обратной совместимости

Да, под первые два пункта подходит. А что насчет:

обращается как 1.0, но шлёт с этим методы и заголовки которые можно только в 1.1

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от deep-purple

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

anonymous
()
Ответ на: комментарий от deep-purple

чаще железки

В таком случае, возможно, придётся и прогибаться под кривые запросы. Добро пожаловать в реальный мир :)

anonymous
()
Ответ на: комментарий от anonymous

Прогнуться всегда успеем. Меня интересует что на этот счёт говорят спеки — must|should и всё такое прочее.

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от anonymous

HTTP uses a «<major>.<minor>» numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather than the features obtained via that communication. No change is made to the version number for the addition of message components which do not affect communication behavior or which only add to extensible field values. The <minor> number is incremented when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may add to the message semantics and imply additional capabilities of the sender. The <major> number is incremented when the format of a message within the protocol is changed.

The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. If the protocol version is not specified, the recipient must assume that the message is in the simple HTTP/0.9 format.

HTTP-Version = «HTTP» «/» 1*DIGIT "." 1*DIGIT

Note that the major and minor numbers should be treated as separate integers and that each may be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. Leading zeros should be ignored by recipients and never generated by senders.

This document defines both the 0.9 and 1.0 versions of the HTTP protocol. Applications sending Full-Request or Full-Response messages, as defined by this specification, must include an HTTP-Version of «HTTP/1.0».

HTTP/1.0 servers must:

recognize the format of the Request-Line for HTTP/0.9 and HTTP/1.0 requests;

understand any valid request in the format of HTTP/0.9 or HTTP/1.0;

respond appropriately with a message in the same protocol version used by the client.

HTTP/1.0 clients must:

recognize the format of the Status-Line for HTTP/1.0 responses;

understand any valid response in the format of HTTP/0.9 or HTTP/1.0.

Proxy and gateway applications must be careful in forwarding requests that are received in a format different than that of the application's native HTTP version. Since the protocol version indicates the protocol capability of the sender, a proxy/gateway must never send a message with a version indicator which is greater than its native version; if a higher version request is received, the proxy/gateway must either downgrade the request version or respond with an error. Requests with a version lower than that of the application's native format may be upgraded before being forwarded; the proxy/gateway's response to that request must follow the server requirements listed above.

deep-purple ★★★★★
() автор топика

RFC 2616 и 2145

An application that sends a request or response message that includes HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant with this specification. Applications that are at least conditionally compliant with this specification SHOULD use an HTTP-Version of  "HTTP/1.1" in their messages, and MUST do so for any message that is  not compatible with HTTP/1.0. For more details on when to send specific HTTP-Version values, see RFC 2145 [36].
An HTTP client SHOULD send a request version equal to the highest version for which the client is at least conditionally compliant, and  whose major version is no higher than the highest version supported by the server, if this is known.  An HTTP client MUST NOT send a version for which it is not at least conditionally compliant.

An HTTP client MAY send a lower request version, if it is known that the server incorrectly implements the HTTP specification, but only after the client has determined that the server is actually buggy.

An HTTP server SHOULD send a response version equal to the highest version for which the server is at least conditionally compliant, and whose major version is less than or equal to the one received in the request.  An HTTP server MUST NOT send a version for which it is not at least conditionally compliant.  A server MAY send a 505 (HTTP Version Not Supported) response if cannot send a response using the major version used in the client's request.

An HTTP server MAY send a lower response version, if it is known or suspected that the client incorrectly implements the HTTP specification, but this should not be the default, and this SHOULD NOT be done if the request version is HTTP/1.1 or greater.

2145 отменён RFC 7230, но мне лень там искать про версионирование.

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 2)
Ответ на: комментарий от vvn_black

RFC 7230

Там то же самое чуть другими словами.

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от vvn_black

То есть простыми словами
- Если клиент просит версию 1.1, и сервер ее поддерживает, то сервер должен ответить 1.1.
- Если клиент просит версию 1.1, а сервер ее НЕ поддерживает (поддерживает только 1.0), то сервер должен ответить 1.0.
- Если клиент просит версию 1.0, и сервер ее поддерживает, то сервер должен ответить 1.0, даже если сервер поддерживает как 1.0, так и 1.1.
- Если клиент просит версию 1.0, а сервер ее НЕ поддерживает, а поддерживает сугубо 1.1, то сервер должен ответить 505 (HTTP Version Not Supported).

Логично.

Но весело будет поддерживать параллельно две версии в одном сервере.

Kroz ★★★★★
()
Ответ на: комментарий от vvn_black

Да, кто эти RFC читает то…

Кое-кто читает.

Kroz ★★★★★
()
Ответ на: комментарий от Kroz

поддерживать параллельно две версии в одном сервере

Да не проблема — врапнуть реализации в разные обработчики и делов. Но тут речь о том что «кто эти RFC читает то», поэтому придётся максимально лояльно относится к кривым запросам клиентов.

deep-purple ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.