Re: Tomcat embedded with Apache Solr
Chris, On Sat, Oct 13, 2018 at 6:41 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > All, > > I've posted a question to the Solr mailing list[1] about why Jetty is > being used instead of Tomcat, and it seems that it's just "always the > way it's been" for the most part. > > These seems to be some interest in moving from their existing model > (Jetty launches, then hosts Solr as a web application) to an embedded > model where a Solr-agent launches and then launches the app server > (e.g. tc) hosting itself. > > Is anyone familiar enough with Solr to whip-up a quick-and-dirty POC > for Tomcat-embedded-hosting-Solr? > The last time I used Solr was about 10 years ago. The Solr API seemed so cumbersome that I opted to embed Apache Lucene directly in my application. And ever since Elasticsearch was launched there was very little incentive to use Solr, as it provided similar functionality (and nowadays arguably better), with a much simpler UI/API. Woonsan's PoC looks very close to getting the job done, possibly missing some Solr config setting or something like that. > I'd like to make the case that Tomcat isn't some big, bad heavy > monster that should be avoided for some other product. There appears > to be soe unfounded hatred[4] going around. > > The Solr team seems especially conscious of runtime memory footprint, > and they don't have any use for JSP, Websocket, or anything fancy. > They just want to pump bytes back and forth to their basic > servlet-based service. > I have seen stuff like that years ago in the Railo project (Lucee's predecessor), where some users made similar claims and insisted on using Jetty. I was never able to confirm those claims in my tests, and most Lucee users run it in Tomcat nowadays. > Can anyone chime-in on that thread referenced below with some thoughts > on how Solr might be able to use Tomcat-embedded as a platform for soe > future version? > I would argue that they should have a container-agnostic configuration. They should really let the end users the freedom to choose their servlet container. Best, Igal > > Also see [2] and [3]. > > Thanks, > - -chris > > [1] > https://lists.apache.org/thread.html/69c3a6ef96d99aa79d5ab15b23e1eb75d8f > 32b0709fa14cc7cdded91@%3Cdev.lucene.apache.org%3E > [2] https://issues.apache.org/jira/browse/SOLR-6733 > [3] https://issues.apache.org/jira/browse/SOLR-6734 ?? > [4] > https://lists.apache.org/thread.html/c5786fd956d6d9029ddacc5af18147d098d > 5a8675ebda78db14c10f1@%3Cdev.lucene.apache.org%3E > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvCnsMACgkQHPApP6U8 > pFiqwA/+PbcFqOUhXacAzRwzBGtK0WELMHrr1QCkPYWw1D6yxgNq2kKya6jWh9XK > +EFb1ZkaYDFunseLsXdLw6pN7fkxPjLRUVFLUr+57csGKR8nH+Y36uaKXErKG1TD > w1PHOIjZkNfN1i5x3aouqZVGwxbqB41HZeXYDmaknNX5yhZGoZQlgLkH8DXZRj4H > qLMIY2WV3q0tUz/9mVi4Lvtvejr01KUiALYxurwxJI9rToLdOEv3qIOk2+sNy5b7 > P8G2eUgMtA7vdXQ+sajXV+KptKkzcNHwehgX0YxYsV56tkaVgWkg6d63KZj11qgm > xWzUpdiGYXXVTFfEPSEVSu3psqBGIHDvv234PMGs2A+sqM8kaynJkbQsJJ7fu9Co > oA7clrptZbyGqVB4ASAxWC+PXeuycGnMFplZRfRXagmcmkChxli+Y2MqFekdKHO6 > VF6ExuzK7gg3ogZ1R+4sHYYW/KBTSaS+OVHXjJvTppATQbsnAGkZ5/93zTdlnbMh > Ua9WOICaOats7XDcDhgpSmClL5SdOWQ+THCeT5hrnI7CttefihdPp4fqrDOPJ0O+ > fhcVv1J80GJIIPq2g48MzmxQoT08tKxomM9EeZbApnV9ptQxz6RgLAYYGryYUqjn > 7v3Aoc6YS6WWEicZ6iR1j3AD5mE/kV0/GxZ8L52MPyVb4gvhiVU= > =/itJ > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat embedded with Apache Solr
Woonsan, On Fri, Oct 26, 2018 at 2:54 PM Woonsan Ko wrote: > Not sure if it helps, but I've spent some hours to test it out for my > curiosity. Embedding tomcat v9 with an example servlet is simple > enough, but it's not working yet with fully initialized Solr: > - https://github.com/woonsan/solr-tomcat > I noticed that you extend Tomcat [1] in order to avoid initializing the default servlets. You may have already seen that, but I wanted to point out that in the next version of Tomcat it can be done by passing false to setAddDefaultWebXmlToWebapp() [2]. Best, Igal [1] https://github.com/woonsan/solr-tomcat/blob/master/server/src/main/java/com/github/woonsan/solr/server/tomcat/launch/Main.java#L103 [2] https://github.com/apache/tomcat/commit/0222ce9 > I'm not there yet to understand the reasons and have fixes. > Let me know if you have any suggestions. > > Cheers, > > Woonsan > > On Fri, Oct 19, 2018 at 9:09 AM Shawn Heisey wrote: > > > > On 10/18/2018 8:55 AM, Christopher Schultz wrote: > > > Actually, my goal was to convince the Solr team that switching from > > > Jetty to Tomcat was (a) possible and (b) possibly attractive. > > > > Over on lucene-dev, I had said that I removed jetty from solr's ivy > > config and found only two classes with errors in eclipse. > > > > Turns out this was because I hadn't removed jetty from the *lucene* ivy > > config, so most of the jetty jars were actually still referenced in the > > eclipse build path. > > > > When I remove jetty from ALL ivy configs, there are 335 compile errors, > > across many more classes. Some of those are on the Lucene side, where I > > have less concern. The part of Lucene that utilizes Jetty is not used > > in Solr. > > > > As I expected, a lot of the errors are in test code, but some of them > > are in code that's not for tests. > > > > If you really want to see us switch to Tomcat, we'll need help fixing > > those errors ... switching the code over to generic APIs (servlet and > > native Java) where possible, and to Tomcat where necessary. I would not > > expect the Tomcat community to actually do the work -- just provide > > expert guidance. Although if anyone was interested in volunteering, I > > wouldn't turn away the help! > > > > Thanks, > > Shawn > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: [EXTERNAL] Re: Tomcat custom location for configuration
Amit, On Fri, Oct 26, 2018 at 9:45 AM Amit Pande wrote: > Thank you once again, Chris and Mark! > > > https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE > > Was able to meet our requirement of moving Tomcat configuration to a > custom location using a different CATALINA_BASE. > Great! > The "-config" option will be cleaned up in next Tomcat release(s), right? > It will probably be removed in a future version, yes. That's what Chris meant in writing: My vote would be to deprecate it immediately and remove it completely >> in Tomcat 10. >> > Best, Igal Thanks, > Amit > > On 10/4/18, 12:15 PM, "Christopher Schultz" > wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Amit, > > On 10/4/18 12:17, Amit Pande wrote: > > Thanks! I will take a detailed relook at using CATALINA_BASE and > > keep you posted. > > > > > > Also, since the "-config" option is there since 4.0.x time till > > now, would it be safe to assume that this option won't be > > deprecated since some users (admittedly not too many) might > > actually be using it? If it's going to stay, do you feel it's worth > > documenting (till the time it isn't actually deprecated with some > > alternate)? > > > > I agree while not desirable at the moment, using "-config" solves > > our problem. So, we might have to use this as last fallback > > option. > > It sounds like this feature barely works and probably doesn't work in > many situations. > > My vote would be to deprecate it immediately and remove it completely > in Tomcat 10. > > I'm sorry, but I don't think I understand why you cannot use > CATALINA_BASE as "usual" in your situation. > > - -chris > > > On 10/4/18, 8:38 AM, "Mark Thomas" wrote: > > > > On 03/10/18 17:18, Amit Pande wrote: > >> Thank you so much, Mark! > >> > >> In our case, the server.xml contains some information which is > >> generated run time (pre-config before Tomcat is started) like the > >> paths to key store and trust store, cipher suites, etc. > >> > >> Also, we have an active-passive cluster setup in which only the > >> currently active node has the access to a shared disk which has > >> all our product configuration data including the key store, > >> trust store files needed in server.xml. > >> > >> We have a requirement to share the configuration across both the > >> nodes of the cluster to avoid keeping duplicate copies of > >> configuration (server.xml). And since some of the server.xml > >> configuration is generated runtime, it isn’t trivial in our case > >> to keep these copies in sync. > >> > >> This is the prime reason to have a shared Tomcat configuration. > >> We may also want, in future, to spawn and additional instance of > >> Tomcat with re-usable configuration (except adjusting the port > >> numbers ). > >> > >> The not-so-elegant choice we might have is to move the entire > >> Tomcat installation to this cluster aware shared storage but > >> defeats the purpose of having a shared disk for configuration > >> data and not the binaries. > >> > >> What alternates should we explore? > > > > You could look at using separate CATALINA_HOME and CATALINA_BASE. > > See > > > > > > > Whether have the web applications on the node or the shared > > storage is arguable either way. If you want it on the node, just > > use an absolute path that points to someone on the node for > > appBase. > > > > Mark > > > > - > > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > > > - > > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu2SrwACgkQHPApP6U8 > pFjlHw/+OZ8FgsTCHvzIIAYBRdAQ+If0M3Q7Wpp7w/tqUYjbHgERPBiof2arPft5 > ir2tfUh11M0YiUvTPXfzzq7BHe5sXsDQHTxLimN1gq6+WOlZVd3k//giFQUmcwsK > RZtKUQUnGWUsjJ/n7z4rWna+gdleukWQ0k7qgbRR/dAiaAUd2mRfy4LgKpHvTVex > y6SXSmcGZ963vzPuZurMIyfPY2iUxb7Y1dbC8Pv7J0vAWhw1we08t33oMJa3Pcp4 > vgV2Ylc6nwyw4LpFcTdNOzWaLIKBwJ4zwv2rQW9Tp8zhiU6O5BfVmzP3Zo04K18x > z1Zvw9mhOISIWn0vE+k6WxU/t17UVKYonPUBwJ0JelVNBE/tGsCSwiHK67gBhs0F > K/+QN8+625TDcUmxYtTMdXQVel/ZvWCrdVZKCJlM3uHSsSySoPhkQU+gCt9PExx9 > YIgxzzViI3NiIkeobf8VmBMtZKaYWLWa6+eSoVVmj8UA7Glj5/tvT8o1AXDerYEk >
Re: Tomcat embedded with Apache Solr
Not sure if it helps, but I've spent some hours to test it out for my curiosity. Embedding tomcat v9 with an example servlet is simple enough, but it's not working yet with fully initialized Solr: - https://github.com/woonsan/solr-tomcat I'm not there yet to understand the reasons and have fixes. Let me know if you have any suggestions. Cheers, Woonsan On Fri, Oct 19, 2018 at 9:09 AM Shawn Heisey wrote: > > On 10/18/2018 8:55 AM, Christopher Schultz wrote: > > Actually, my goal was to convince the Solr team that switching from > > Jetty to Tomcat was (a) possible and (b) possibly attractive. > > Over on lucene-dev, I had said that I removed jetty from solr's ivy > config and found only two classes with errors in eclipse. > > Turns out this was because I hadn't removed jetty from the *lucene* ivy > config, so most of the jetty jars were actually still referenced in the > eclipse build path. > > When I remove jetty from ALL ivy configs, there are 335 compile errors, > across many more classes. Some of those are on the Lucene side, where I > have less concern. The part of Lucene that utilizes Jetty is not used > in Solr. > > As I expected, a lot of the errors are in test code, but some of them > are in code that's not for tests. > > If you really want to see us switch to Tomcat, we'll need help fixing > those errors ... switching the code over to generic APIs (servlet and > native Java) where possible, and to Tomcat where necessary. I would not > expect the Tomcat community to actually do the work -- just provide > expert guidance. Although if anyone was interested in volunteering, I > wouldn't turn away the help! > > Thanks, > Shawn > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Hostnames with underscores
On October 26, 2018 5:02:25 PM UTC, "M. Manna" wrote: >Have you checked the connector config doc for relaxedPathChars and >relaxedQueryChars? Those options have no impact on the parsing of the hist name. >On Fri, 26 Oct 2018 at 18:00, Amit Pande >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) >> 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? The host names are invalid and should be fixed. Generally, Tomcat does not provide options to break spec compliance unless there is a compelling case to do so. I haven't seen such a case made for relaxing the host name parsing. >> Are there any other alternates to help solve this issue? Short of patching Tomcat yourself (not a course of action I recommend), no. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXTERNAL] Re: Hostnames with underscores
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 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 manme...@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.pa...@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
> .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
>at 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
>
>
>
>
>
>
>
Re: [EXTERNAL] Re: Hostnames with underscores
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
mailto:manme...@gmail.com>> wrote:
Have you checked the connector config doc for relaxedPathChars and
relaxedQueryChars?
On Fri, 26 Oct 2018 at 18:00, Amit Pande
mailto:amit.pa...@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
.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
at 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
Re: Hostnames with underscores
Have you checked the connector config doc for relaxedPathChars and relaxedQueryChars? On Fri, 26 Oct 2018 at 18:00, Amit Pande 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 > .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498) > at 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 > > > > > >
Hostnames with underscores
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.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498) at 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
Re: [EXTERNAL] Re: Tomcat custom location for configuration
Thank you once again, Chris and Mark! https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE Was able to meet our requirement of moving Tomcat configuration to a custom location using a different CATALINA_BASE. The "-config" option will be cleaned up in next Tomcat release(s), right? Thanks, Amit On 10/4/18, 12:15 PM, "Christopher Schultz" wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Amit, On 10/4/18 12:17, Amit Pande wrote: > Thanks! I will take a detailed relook at using CATALINA_BASE and > keep you posted. > > > Also, since the "-config" option is there since 4.0.x time till > now, would it be safe to assume that this option won't be > deprecated since some users (admittedly not too many) might > actually be using it? If it's going to stay, do you feel it's worth > documenting (till the time it isn't actually deprecated with some > alternate)? > > I agree while not desirable at the moment, using "-config" solves > our problem. So, we might have to use this as last fallback > option. It sounds like this feature barely works and probably doesn't work in many situations. My vote would be to deprecate it immediately and remove it completely in Tomcat 10. I'm sorry, but I don't think I understand why you cannot use CATALINA_BASE as "usual" in your situation. - -chris > On 10/4/18, 8:38 AM, "Mark Thomas" wrote: > > On 03/10/18 17:18, Amit Pande wrote: >> Thank you so much, Mark! >> >> In our case, the server.xml contains some information which is >> generated run time (pre-config before Tomcat is started) like the >> paths to key store and trust store, cipher suites, etc. >> >> Also, we have an active-passive cluster setup in which only the >> currently active node has the access to a shared disk which has >> all our product configuration data including the key store, >> trust store files needed in server.xml. >> >> We have a requirement to share the configuration across both the >> nodes of the cluster to avoid keeping duplicate copies of >> configuration (server.xml). And since some of the server.xml >> configuration is generated runtime, it isn’t trivial in our case >> to keep these copies in sync. >> >> This is the prime reason to have a shared Tomcat configuration. >> We may also want, in future, to spawn and additional instance of >> Tomcat with re-usable configuration (except adjusting the port >> numbers ). >> >> The not-so-elegant choice we might have is to move the entire >> Tomcat installation to this cluster aware shared storage but >> defeats the purpose of having a shared disk for configuration >> data and not the binaries. >> >> What alternates should we explore? > > You could look at using separate CATALINA_HOME and CATALINA_BASE. > See > > > Whether have the web applications on the node or the shared > storage is arguable either way. If you want it on the node, just > use an absolute path that points to someone on the node for > appBase. > > Mark > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu2SrwACgkQHPApP6U8 pFjlHw/+OZ8FgsTCHvzIIAYBRdAQ+If0M3Q7Wpp7w/tqUYjbHgERPBiof2arPft5 ir2tfUh11M0YiUvTPXfzzq7BHe5sXsDQHTxLimN1gq6+WOlZVd3k//giFQUmcwsK RZtKUQUnGWUsjJ/n7z4rWna+gdleukWQ0k7qgbRR/dAiaAUd2mRfy4LgKpHvTVex y6SXSmcGZ963vzPuZurMIyfPY2iUxb7Y1dbC8Pv7J0vAWhw1we08t33oMJa3Pcp4 vgV2Ylc6nwyw4LpFcTdNOzWaLIKBwJ4zwv2rQW9Tp8zhiU6O5BfVmzP3Zo04K18x z1Zvw9mhOISIWn0vE+k6WxU/t17UVKYonPUBwJ0JelVNBE/tGsCSwiHK67gBhs0F K/+QN8+625TDcUmxYtTMdXQVel/ZvWCrdVZKCJlM3uHSsSySoPhkQU+gCt9PExx9 YIgxzzViI3NiIkeobf8VmBMtZKaYWLWa6+eSoVVmj8UA7Glj5/tvT8o1AXDerYEk kNWojPCOMx1l6rgysrlX6pRY3ltDnqGmlkzhxrU72afUXMpZ9VhKVawZ5457SEan mYWGR5o09lmUE4VBFt87yL+VVSdmlckrC/2hQjDbK6qHQMUDIM6fs98mJ/fgVE2m pL9gZG/4J3Tp6nQEFuAKehtFO+aQmRk6UKP6iW+ux2iarzQ5Z7k= =32WJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
