Re: {[OT] Re: Setting up Tomcat behind an existing Apache httpd server (on Amazon Linux 2)
I don't have enough reputation points to comment on your question on serverfault. Is your DocumentRoot (/var/www/html/test) underneath the default DocumentRoot (normally /var/www/html)? I found the problem, and it wasn't a [profanity] server problem; it was a [profanity] client problem! This morning, I looked at the server access log, and found that I was only showing up if I explicitly asked for the test page. So then, I used a utility called "Postman" to do a GET on "http://qux.baz.com;, and THAT retrieved the test page just fine. So then, I bit the [profanity] bullet, and cleared every-[profanity]-thing out of both Firefox and Chrome: history, cookies, persistent sign-ons, everything. And suddenly, "http://qux.baz.com; started working just fine. And I'm suddenly very fluent in "Army Creole," and when I'm no longer swearing every other [profanity] word, ready to take the next step with this thing. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: Re: Re: /META-INF/resources/ and Chrome's DevTools
Ah ok, I use maven, only tomcat 7 and 6 is available. PreResources are only available in tomcat8 so I decide against tomcat in higher versions than 7. Kind regards > Gesendet: Montag, 06. April 2020 um 16:34 Uhr > Von: "Mark Thomas" > An: users@tomcat.apache.org > Betreff: Re: Aw: Re: /META-INF/resources/ and Chrome's DevTools > On 06/04/2020 09:16, Peter Rader wrote: > > Hello Konstantin Kolinko, > > > > I tried to use the PreResource but it does not work. > > > > 2020-04-06 10:13:05 WARNUNG org.apache.tomcat.util.digester.Digester > endElement No rules found matching 'Context/Resources/PreResources'. > > > > This is my context.xml > > > > > > > type="javax.sql.DataSource" driverClassName="org.postgresql.Driver" > > url="" > > username="xxx" password="xxx" maxTotal="50" > > maxIdle="50" maxWait="10"> > > > > > className="org.apache.catalina.webresources.FileResourceSet" > > base="C:\Users\Guest\git\x\src\main\resources\META-INF\resources" > > internalPath="index.html" /> > > That doesn't look quite right. I'd expect it to look something like: > > className="org.apache.catalina.webresources.FileResourceSet" > base="C:\Users\Guest\git\x\src\main\resources\META-INF\resources" > /> > > To map the contents of the "...\META-INF\resources" directory into the > root of the web application. > > 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
Re: Issue with Host Header Mismatch
On 07/04/2020 08:54, Rajah Yoghindra K S wrote: > Our POST request header looks like this: > > POST https://linux-7f67.blr.abc.com:443/testUrl/ HTTP/1.1 > Host: *linux-7f67.blr.abc.com* > User-Agent: gSOAP/2.8 > Content-Type: text/xml; charset=utf-8 > Content-Length: 1740 > Connection: close > What is your take on this ? Should the code in tomcat be checking just > the fqdn without the port ? >From RFC 7230, section 5.4 Host A client MUST send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client MUST send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (Section 2.7.1). So, the check Tomcat is performing is correct. The client is broken and needs to be fixed. > Also would it be possible to include a fix so that it skips the default > port (if present) and then compare? Non default ports to be still > retained. Only default ports to be skipped. Possible, yes. Likely to be accepted, no. The starting position that the Tomcat committers typically take is that we don't apply workarounds for broken clients that aren't specification compliant. Exceptions are made but generally only when a large number of users are likely to be affected AND the broken client in question is unlikely / has already refused to apply a fix. That doesn't look to be the case in this instance. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: javax.servlet.ServletContainerInitializer defined in jar not loading on Tomcat 8.5.51 and above
On 07/04/2020 08:09, Jackson Ong wrote: > Hi, > > I have tested 8.5.51 and 8.5.53, both doesn't work. The current version > that works for me is tomcat 8.5.50 > The recent changed on SCI was tomcat 7.0.103 ( > https://tomcat.apache.org/tomcat-7.0-doc/changelog.html) > Previously we have issue with tomcat 7.0.100 to 102, tested it works in > 7.0.103. Can you test with the 8.5.54 release candidate please? Details on how to obtain it are on the dev@ list. If you still see an issue, please create the simplest possible test case that recreates the issue and provide the steps necessary to recreate the issue from a clean 8.5.54 install. Thanks, Mark > > Jackson > > On Tue, Apr 7, 2020 at 2:51 PM Martin Grigorov wrote: > >> Hi, >> >> On Tue, Apr 7, 2020 at 9:01 AM Jackson Ong <83cl...@gmail.com> wrote: >> >>> We have an webapp running fine on Tomcat 8.5.50 and below and we used a >>> custom WebappClassLoader to load jars (common path for jars), but it >> failed >>> to load on Tomcat 8.5.51 and above. Upon checking, we noticed that >>> >> >> Which versions of "above" you have tried ? >> Because there was a regression with SCI recently that have been fixed in >> 8.5.53 (I think. Better check the changelogs). >> 8.5.54 is being tested at the moment and if no issues are found it will be >> released in the next few days. >> >> Martin >> >> >>> javax.servlet.ServletContainerInitializer that we defined in the jar is >> not >>> being loaded. >>> >>> From org.apache.catalina.startup.WebappServiceLoader source code of >> Tomcat >>> 8.5.51, the classLoader was changed from servletContext.getClassloader() >>> (Tomcat 8.5.50 line 97) to context.getParentClassLoader() (Tomcat 8.5.51 >>> line 144) >>> >>> However placing the jar at WEB-INF/lib it was able to load >>> javax.servlet.ServletContainerInitializer. The problem is when the jar is >>> outside of WEB-INF/lib or common path (/opt/client/libraries/test.jar). >>> >>> Thanks >>> >> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Issue with Host Header Mismatch
Hello everyone, Tomcat Version: 9.0.26 OS: Windows and Linux We recently upgraded from Tomcat 8.5.35 to 9.0.26 and in 9.0.26 there is change in default value of "allowHostHeaderMismatch" flag which is causing few issues for us. 8.5.35 - Default value of allowHostHeaderMismatch is true. So it ALLOWS requests where the host headers don't match . 9.0.26 - Default value of allowHostHeaderMismatch is false. So it BLOCKS requests where the host headers don't match . Our POST request header looks like this: POST https://linux-7f67.blr.abc.com:443/testUrl/ HTTP/1.1 Host: linux-7f67.blr.abc.com User-Agent: gSOAP/2.8 Content-Type: text/xml; charset=utf-8 Content-Length: 1740 Connection: close The content on the "Host" field i.e. "Host: linux-7f67.blr.abc.com" is generated by gSOAP library and it ignores adding the port as it to talking to a default port. The uri on the "POST" line i.e. "https://linux-7f67.blr.abc.com:443/testUrl/ " is generated by another tool and it seems to be explicit about the port even though it is using the default port. There is some confusion in general on the internet about including Port in URL for default ports. Some say it is ok to include and some say it is redundant when using default port. The check in tomcat at https://github.com/apache/tomcat/blob/ca66cfd3d6fae198fbcf76be09b3e8f3f8232c0a/java/org/apache/coyote/http11/Http11Processor.java#L686 compares "linux-7f67.blr.abc.com" in Host to "linux-7f67.blr.abc.com:443" in the POST url and tomcat returns a 400 Badrequest because of the extra :443 in the URL. [cid:image003.jpg@01D60CDF.A04BF0A0] What is your take on this ? Should the code in tomcat be checking just the fqdn without the port ? Also would it be possible to include a fix so that it skips the default port (if present) and then compare? Non default ports to be still retained. Only default ports to be skipped. Regards Rajah Yoghindra
Re: javax.servlet.ServletContainerInitializer defined in jar not loading on Tomcat 8.5.51 and above
Hi, I have tested 8.5.51 and 8.5.53, both doesn't work. The current version that works for me is tomcat 8.5.50 The recent changed on SCI was tomcat 7.0.103 ( https://tomcat.apache.org/tomcat-7.0-doc/changelog.html) Previously we have issue with tomcat 7.0.100 to 102, tested it works in 7.0.103. Jackson On Tue, Apr 7, 2020 at 2:51 PM Martin Grigorov wrote: > Hi, > > On Tue, Apr 7, 2020 at 9:01 AM Jackson Ong <83cl...@gmail.com> wrote: > > > We have an webapp running fine on Tomcat 8.5.50 and below and we used a > > custom WebappClassLoader to load jars (common path for jars), but it > failed > > to load on Tomcat 8.5.51 and above. Upon checking, we noticed that > > > > Which versions of "above" you have tried ? > Because there was a regression with SCI recently that have been fixed in > 8.5.53 (I think. Better check the changelogs). > 8.5.54 is being tested at the moment and if no issues are found it will be > released in the next few days. > > Martin > > > > javax.servlet.ServletContainerInitializer that we defined in the jar is > not > > being loaded. > > > > From org.apache.catalina.startup.WebappServiceLoader source code of > Tomcat > > 8.5.51, the classLoader was changed from servletContext.getClassloader() > > (Tomcat 8.5.50 line 97) to context.getParentClassLoader() (Tomcat 8.5.51 > > line 144) > > > > However placing the jar at WEB-INF/lib it was able to load > > javax.servlet.ServletContainerInitializer. The problem is when the jar is > > outside of WEB-INF/lib or common path (/opt/client/libraries/test.jar). > > > > Thanks > > >
Re: javax.servlet.ServletContainerInitializer defined in jar not loading on Tomcat 8.5.51 and above
Hi, On Tue, Apr 7, 2020 at 9:01 AM Jackson Ong <83cl...@gmail.com> wrote: > We have an webapp running fine on Tomcat 8.5.50 and below and we used a > custom WebappClassLoader to load jars (common path for jars), but it failed > to load on Tomcat 8.5.51 and above. Upon checking, we noticed that > Which versions of "above" you have tried ? Because there was a regression with SCI recently that have been fixed in 8.5.53 (I think. Better check the changelogs). 8.5.54 is being tested at the moment and if no issues are found it will be released in the next few days. Martin > javax.servlet.ServletContainerInitializer that we defined in the jar is not > being loaded. > > From org.apache.catalina.startup.WebappServiceLoader source code of Tomcat > 8.5.51, the classLoader was changed from servletContext.getClassloader() > (Tomcat 8.5.50 line 97) to context.getParentClassLoader() (Tomcat 8.5.51 > line 144) > > However placing the jar at WEB-INF/lib it was able to load > javax.servlet.ServletContainerInitializer. The problem is when the jar is > outside of WEB-INF/lib or common path (/opt/client/libraries/test.jar). > > Thanks >
javax.servlet.ServletContainerInitializer defined in jar not loading on Tomcat 8.5.51 and above
We have an webapp running fine on Tomcat 8.5.50 and below and we used a custom WebappClassLoader to load jars (common path for jars), but it failed to load on Tomcat 8.5.51 and above. Upon checking, we noticed that javax.servlet.ServletContainerInitializer that we defined in the jar is not being loaded. >From org.apache.catalina.startup.WebappServiceLoader source code of Tomcat 8.5.51, the classLoader was changed from servletContext.getClassloader() (Tomcat 8.5.50 line 97) to context.getParentClassLoader() (Tomcat 8.5.51 line 144) However placing the jar at WEB-INF/lib it was able to load javax.servlet.ServletContainerInitializer. The problem is when the jar is outside of WEB-INF/lib or common path (/opt/client/libraries/test.jar). Thanks
