Re: Multiple Host Ambiguity

Hi,

On Thu, May 05, 2016 at 01:32:14PM -0700, Jian Jiang wrote:
> 1). Whitespace is a major source of multiple Host ambiguity. My
> understanding is that only until RFC 7230, whitespace around field-name is
> explicitly forbidden. But the message is somewhat confusing. For whitespace
> between field-name and colon, the rule in RFC 7230 is clear: rejection with
> 400. But for whitespace before field-name, the main body of RFC 7230
> (section 3) only says if whitespace appears before the first header field,
> either the request should be rejected or the header should be ignored. The
> clear rule is located at Appendix A.2: "invalid whitespace around
> field-names is required to be rejected ...". An uncareful read of the
> document would have missed this message. We have seen that implementations
> in general are more tolerant with whitespace-preceded Host header than
> whitespace-succeeded Host header.

A whitespace *before* a field name indicates a continuation of the
previous header field, which is called folding. It as been deprecated
in 7230 because it often is incorrectly implemented if at all, and was
a great cause of trouble.

(...)
> 3). Multiple Host header fields is explicitly forbidden in RFC 7230 (not in
> RFC 2616). But again only a few follow this requirement.
(...)
> 4). My general feeling is that RFC 7230 is clear in how host should be
> parsed from a request. But these rules are located in different places,
> quite easy to miss when doing implementation.

In general, keep in mind that 7230 is young compared to implementations,
the most important thing is that implementations have something to refer
to when users report bugs so that ultimately interoperability increases.
You should not expect every implementation to suddenly comply with 7230
because many are probably even not aware that this work was done (aside
those who participated of course).

Regards,
Willy

Received on Friday, 6 May 2016 10:38:33 UTC