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 ? Кроме того, в разделе 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-м статусом не будет лучше? -- Best regards, Gena _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
