Hello! On Sun, Jun 15, 2014 at 11:07:58PM +0300, Gena Makhomed wrote:
> On 14.06.2014 21:14, Maxim Dounin wrote: > > >>>>>>>>>>>>http://habrahabr.ru/post/166855/ > ... > >Прокси-сервер, помимо всего прочего, является сервером, и > >процитированное требование вернуть 400 в ответ на "Host header > >field with an invalid field-value" - к нему тоже относится. > >Соответственно, если трактовать термин "invalid field-value" как > >включающий проверку не только синтаксиса, но и требований, > >предъявляемых к формированию заголовка Host клиентом, то > >требование "ignore the received Host header" теряет смысл. > > Максим, теперь я понял, в чем была моя ошибка, спасибо! > > >Теримн "field-value" расшифровывается в "3.2. Header Fields", > >http://tools.ietf.org/html/rfc7230#section-3.2: > > > > field-value = *( field-content / obs-fold ) > > > >Соответственно invalid - это то, что не соответствует указанному > >синтаксису. > > Понял, спасибо! > > Но есть один не совсем понятный нюанс - > озвученные в RFC 7230 требования к клиенту: > > 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). > > - это ведь требования к синтаксису, которые обязательны для выполнения. Нет, это не требования к синтаксису, это требования к семантике. И они обязательны для клиента, но не для сервера. Соответственно, что делать в случае, если клиент их не выполнил - на совести сервера. > А вот что есть в RFC 7231: > > http://tools.ietf.org/html/rfc7231#section-6.5.1 > > 6.5.1. 400 Bad Request > > The 400 (Bad Request) status code indicates that the server cannot or > will not process the request due to something that is perceived to be > a client error (e.g., malformed request syntax, invalid request > message framing, or deceptive request routing). > > Следовательно, сервер имеет право вернуть 400 статус, > если получит запрос с разными authority component > в заголовке Host и в absolute Request URI ? Сервер имеет право вернуть 400 более или менее в любой момент. > Кроме того, в разделе 5.5. Effective Request URI > http://tools.ietf.org/html/rfc7230#section-5.5 > > даже прямо говорят, что запрос может быть misdirected, > deliberately or accidentally, и что origin server должен > сам решить, обрабатывать такой запрос или нет, потому что > "it might indicate an attempt to bypass security filters, > trick the server into delivering non-public content, > or poison a cache." > > именно это ведь и происходит в случае запроса > > GET http://apple.com/ HTTP/1.1 > Host: samsung.com > > Разве ответить на такой запрос 400-м статусом не будет лучше? Это зависит от многих факторов. Вот тут Валентин давеча напрограммировал возврат 400, если имя, указанное в SNI, не совпадало с именем, используемым в запросе, ибо RFC 6066 говорит: ... If the server_name is established in the TLS session handshake, the client SHOULD NOT attempt to request a different server name at the application layer. Так пришлось распрограмировать обратно - потому что Chrome использует "a different server name at the application layer", когда считает нужным/возможным. То, как ведёт себя nginx по умолчанию - вполне себе безопасно, и проблемы нет. Какая-либо проблема появляется тогда и только тогда, когда администратор начинает писать в конфиге $http_host, не думая о последствиях. Есть мнение, что совсем простое решение этой проблемы - не делать так (c) анекдот. -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
