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

Reply via email to