On 22/03/17 14:13, Konstantin Kolinko wrote: > 2017-03-21 18:01 GMT+03:00 Mark Thomas <ma...@apache.org>: >> On 21 March 2017 14:14:19 GMT+00:00, Christopher Schultz >> <ch...@christopherschultz.net> wrote: >>> >>> How about an option to disable the validity-checking, in case someone >>> in the field finds a case they need to support, or if they don't care >>> about hostname-checking and want their "performance back"? >> >> I'm not too concerned about performance. The checks are at most 1% of the >> current processing time for a trivial servlet accessed over localhost. For >> real use cases it will be less. >> >> Some form of transition could work (eg log only) but I'm reluctant to an an >> option that effectively bypasses spec compliance. > > This needs a definition of "spec". > > I am afraid that DNS spec may evolve over time. > > > 1) https://tools.ietf.org/html/rfc7230 > RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 > > Host = uri-host [ ":" port ] ; Section 2.7.1 > > uri-host = <host, see [RFC3986], Section 3.2.2> > > > 2) https://tools.ietf.org/html/rfc3986 > RFC 3986 URI Generic Syntax January 2005 > > Updated by: 6874, 7320 > > host = IP-literal / IPv4address / reg-name > > IP-literal = "[" ( IPv6address / IPvFuture ) "]" > > but RFC 6874 updates the syntax and changes "IP-literal" into > > IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture ) "]" > > ZoneID = 1*( unreserved / pct-encoded ) > > IPv6addrz = IPv6address "%25" ZoneID > > > reg-name = *( unreserved / pct-encoded / sub-delims ) > > pct-encoded = "%" HEXDIG HEXDIG > > > DomainParseState in r1787662 is more strict and I see no support for > pct-encoded characters there. > > IPv6addrz is not supported > (I mentioned in my previous e-mail, and above is the formal syntax for it) > > IPvFuture address - I think it is too early to implement it, > but it can be a reason to have a flag to turn off this check, > > > An example of IPvFuture address with HTTPd, and its response (400): > https://bz.apache.org/bugzilla/show_bug.cgi?id=55362 > > So apparently Apache HTTP Server already has some validation of Host header.
I'll take a look at the spec references you quoted. The ideal would be if we could apply a general rule now and make it more specific over time. Not sure how possible that would be. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org