[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-user
Subject:    Re: [EXTERNAL] Re: Hostnames with underscores
From:       "M. Manna" <manmedia () gmail ! com>
Date:       2018-10-26 17:28:07
Message-ID: CANmFojqUx+CUt=K_=Mi9y8e_BNvF1vg-8O4_kD1humwo5HNt9w () mail ! gmail ! com
[Download RAW message or body]


Read the description on RFC 7230 and 3986 - just to be sure. You might be
right after all.



On Fri, 26 Oct 2018 at 18:25, Amit Pande <Amit.Pande@veritas.com> wrote:

> Yes, I did check the description, but did not find reference to underscore.
>
> From the documentation:
> "The value may be any combination of the following characters: " < > [ \ ]
> ^ ` { | } . "
>
> But I admit that I did not actually verify it and will see if these
> attributes work for underscore too.
>
> Thanks,
> Amit
>
> On Oct 26, 2018, at 12:02 PM, M. Manna <manmedia@gmail.com<mailto:
> manmedia@gmail.com>> wrote:
>
> Have you checked the connector config doc for relaxedPathChars and
> relaxedQueryChars?
>
>
>
> On Fri, 26 Oct 2018 at 18:00, Amit Pande <Amit.Pande@veritas.com<mailto:
> Amit.Pande@veritas.com>> wrote:
>
> Hello all,
>
> Recent Tomcat versions (8.5.32 I think) has made a stricter validation for
> hostnames with underscores in it. (
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62371)
>
> This is understandably for addressing security issues (
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6816) and
> enforcing RFC compliance, in some way.
>
> Our recent upgrade to Tomcat (8.5.34), we observed:
>
> Note: further occurrences of request parsing errors will be logged at
> DEBUG level.
> java.lang.IllegalArgumentException: The character [_] is never valid in a
> domain name.
>        at
>
> org.apache.tomcat.util.http.parser.HttpParser$DomainParseState.next(HttpParser.java:946)
>        at
>
> org.apache.tomcat.util.http.parser.HttpParser.readHostDomainName(HttpParser.java:842)
>        at org.apache.tomcat.util.http.parser.Host.parse(Host.java:66)
>        at org.apache.tomcat.util.http.parser.Host.parse(Host.java:40)
>        at
> org.apache.coyote.AbstractProcessor.parseHost(AbstractProcessor.java:286)
>        at
>
> org.apache.coyote.http11.Http11Processor.prepareRequest(Http11Processor.java:1203)
>        at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:776)
>        at
>
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
>        at
>
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
>        at org.apache.tomcat.util.net<http://org.apache.tomcat.util.net>
> .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
>        at org.apache.tomcat.util.net<http://org.apache.tomcat.util.net>
> .SocketProcessorBase.run(SocketProcessorBase.java:49)
>        at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>        at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>        at
>
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>        at java.lang.Thread.run(Thread.java:748)
>
>
> The main issue for us now is that, since we ship Tomcat with our product
> (IOW Tomcat runs in customer environments), this will break our product
> functionality if customers have hostnames with underscore. Ideally, they
> should correct the host names (to be RFC compliant) but customers would be
> really averse to change hostname as it might a widespread change in their
> environments.
>
> With Spring also, we ran into same issue but in later releases of Spring
> this was fixed. I
>
> Would it be a good idea to make this strict check configurable so that we
> can continue to cater to our customers without breaking the functionality?
>
> Are there any other alternates to help solve this issue?
>
> Thanks,
> Amit
>
>
>
>
>
>
>


[prev in list] [next in list] [prev in thread] [next in thread]