200 OK HTTP/1.0-1.1

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

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

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

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

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

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

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

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

чаще железки

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

Что-то ты в формализм ударился. У тебя есть возможность изменить под себя клиента?

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

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.

в формализм ударился

Просто я зануда. Ты незнал?

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, но мне лень там искать про версионирование.

Не.

О, тоже годно. Спасибо!

RFC 7230

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

То есть простыми словами
- Если клиент просит версию 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).

Логично.

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

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

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

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

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

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