Hello! On Tue, Jun 17, 2014 at 01:31:16PM +0300, Gena Makhomed wrote:
> On 17.06.2014 9:30, Maxim Dounin wrote: > > >>>>http://tools.ietf.org/html/rfc7230#section-5.4 > >>>> > >>>> A client MUST send a Host header field in all HTTP/1.1 request > >>>> messages. If the target URI includes an authority component, then a > >>>> client MUST send a field-value for Host that is identical to that > >>>> authority component, excluding any userinfo subcomponent and its "@" > >>>> delimiter (Section 2.7.1). > >>>> > >>>>- это ведь требования к синтаксису, которые обязательны для выполнения. > >>> > >>>Нет, это не требования к синтаксису, это требования к семантике. > >> > >>Запись target URI в виде valid request message - это разве не syntax? > > > >Синтаксис - это то, что нарушает требования приведённых нормативных > >грамматик, см. http://tools.ietf.org/html/rfc7231#section-1.2 и > >далее. > > Не все требования к синтаксису выражены в виде нормативных грамматик. > Например, требование отправлять первой строкой запроса request-line > - это тоже требование к синтаксису валидной HTTP request message. > Но это требование не выражено в виде Augmented Backus-Naur Form. http://tools.ietf.org/html/rfc7230#appendix-B HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body ] status-line = HTTP-version SP status-code SP reason-phrase CRLF > >>"SHOULD NOT" - это не запрет, а только лишь рекомендация: > >>http://tools.ietf.org/html/rfc2119#section-4 > >>так что формально и фактически Chrome ничего не нарушает. > > > >Фактически - упомянутый "SHOULD NOT" на тот момент безусловно > >отклонялся Apache'ом, > > И это безусловный BUG апача, копировать его в nginx - нет смысла. > Apache ведь не является reference implementation протокола HTTP/1.1 Это не баг - как уже говорилось выше, вернуть 400 сервер может в любой момент. Это ровно такое же решение авторов апача, как и предлагаемый возврат 400 в случае несовпадения Host и host'а из request line. > >а противоречащие друг другу Host + > >Request-Line - формально вообще ничего не нарушали > > Вообще-то в RFC 2616 написано в точности то же самое что и в RFC 7230: > > http://tools.ietf.org/html/rfc2616#section-14.23 > > The Host request-header field specifies the Internet host and port > number of the resource being requested, as obtained from the original > URI given by the user or referring resource (generally an HTTP URL, > as described in section 3.2.2). The Host field value MUST represent > the naming authority of the origin server or gateway given by the > original URL. This allows the origin server or gateway to > differentiate between internally-ambiguous URLs, such as the root "/" > URL of a server for multiple host names on a single IP address. > > Здесь точно так же присутствует требование "MUST", > то есть клиент, который не выполнил это требование - > прислал на сервер невалидный запрос и сервер имеет > полное право ответить на такой запрос статусом 400. Здесь нет каких-либо явных требований о совпадении Host и host'а из request-line. Что касается "имеет полное право", то руководствующийся RFC 2616 сервер не имеет права ответить на такой запрос 400, так как "MUST ignore". Этот вопрос, мне помнится, Валентин уже прояснял. > >до выхода HTTPbis. > > Выход HTTPbis так и не состоялся. Вместо этого - решили > уточнить спецификацию протокола HTTP/1.1 и сконцентировать > свои усилия в работе над протоколом HTTP/2.0 на базе SPDY, > насколько мне известно. HTTPbis - рабочая группа, созданная для уточнения HTTP/1.1. И именно набор RFC 7230 .. 7237 - основной результат её работы, aka HTTPbis. http://trac.tools.ietf.org/wg/httpbis/trac/wiki > >И что на самом деле происходит в реальной жизни > >- это отдельный интересный вопрос. > > В реальной жизни я не встречал софта, который бы создавал запросы > > GET http://apple.com/ HTTP/1.1 > Host: samsung.com > > и ожидал бы, что такой запрос будет нормально обработан сервером. Такой софт, безусловно, встретить сложно. Проблема в том, что зачастую разный странный софт занимается модификацией запросов, и результаты могут быть малопредсказуемы. > >Среди прочего, например, HTTPbis явно требует возвращать 400, > >если запрос содержит несколько заголовков Host. > > Нет смысла отправлять несколько одинаковых заголовков > с одинаковым значением. А разных значений там быть не должно. > > Единственное что добавилось в RFC 7230 - это более явное требование, > чтобы такой заголовок был всего один. В RFC 2616 это было между строк. Угу, и именно так поступал nginx до упомянутого коммита. Только не работает. Из совсем свежих примеров - Opera при работе по SPDY присылает два заголовка Content-Length. Ну и кто они после этого? > >В своё время, однако, nginx'у потребовалось от этой практики отказаться: > > > >http://hg.nginx.org/nginx/rev/b9de93d804ea > > > >Если мне не изменяет память, причина была всё та же - реальная > >жизнь заставила. > > Можно подробнее узнать про причину? Это вопрос к Игорю, может быть он помнит подробности. -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru