AW: JVM Crash in tcnative due to concurrency/timing in HTTP/2
Mark, > On 09/06/17 16:02, Kreuser, Peter wrote: > > Hi all, > > > > Sorry for the long text. I hope somebody can help me track down the problem > > I'm facing with Tomcat (8.5.15), tcnative (1.2.12), openssl (1.1.0e) and > > HTTP/2. JVM is zulu-8.21.0.1 (1.8.0_131-b11) > > No need to apologise. There was enough information in this report for me > to be 95% sure of what was going on before I tested things locally. > > > > > Would be nice if somebody here could tell me if that is a bug or if I have > > some misconfiguration. > > It is a bug. > > The short explanation is that with NIO2, the style of the API (async > read/write with CompletionHandlers) means that a TLS connection can get > closed down (by a CompletionHandler) before the access log entry is > written. This leads to passing a NULL reference to some native code > which - unsurprisingly - falls over (Tomcat is meant to make sure it > doesn't pass NULL references). > > There is an easy fix but the side-effect is that sometimes the cipher > suite name won't appear in the access log. Depending on timing on your > system that could be very frequent to almost never. I'd roughly expect > it to happen as frequently as the crashes. > > The harder fix is to note that we want the info and to ensure we cache > it before the TLS connection is closed down. In theory, we could do this > in the access log but it means parsing the request attribute config. > Performance wise, there will be an impact on users since the lookup to > populate the cache will occur during request processing rather than > afterwards. However, overall throughput should be unaffected. > > An alternative fix is for the application to trigger the caching of the > TLS info by requesting one of the TLD attributes. > > Switching to NIO should also fix this. Note, I would not expect NIO and > NIO2 to be much different performance wise. > > Would the easy fix be sufficient? > > Mark For a start the easy fix would be sufficient. Apparently this is only a real problem when I call the site via curl, as it does not happen in the various browsers (at least not on every call). We should at least make users aware that certain information can be missing in the accesslog and the cause of it (in the AccessLogValve documentation?). And are there any other implications of the asynchronicity? I guess the behavior of NIO2 and HTTP/2 processing is not obvious? Your alternative fix would be to copy the attributes during request processing (in a filter) and then log them from the filter request attributes instead of the predefined ssl attributes? Correct? Thank you for your support and the bug fix ;-)! Have you filed the bug internally or should I? Best regards Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
REST issue
Some foundation facts: Development environment using NetBeans 8.0.2, Tomcat 8.0.32, Java jdk1.8.0_121 and Postman. The code: I have a simple hello world servlet for testing (in production, the service will serve as an endpoint for information from another organization): package com.tsr.webservices; import javax.jws.WebService; import javax.jws.WebMethod; import javax.jws.WebParam; import javax.ws.rs.Consumes; import javax.ws.rs.GET; import javax.ws.rs.POST; import javax.ws.rs.Path; import javax.ws.rs.PathParam; import javax.ws.rs.Produces; import javax.ws.rs.core.MediaType; import org.json.JSONObject; /** * * @author Carl */ @WebService(serviceName = "helloWorld") @Path("/helloWorld") public class AnoviaWebService { /** * Retrieves representation of an instance of helloWorld.HelloWorld * @return an instance of java.lang.String */ @GET @Produces("text/html") public String getHtml() { return "Hello, World!!"; } } The web.xml contains these fragments: ... AnoviaWebService org.glassfish.jersey.servlet.ServletContainer jersey.config.server.provider.packages com.tsr.webservice 1 ... AnoviaWebService /helloWorld/* ... Tomcat starts properly with no errors. Using Postman with either http://192.168.0.117:8080/prod2test/helloWorld/getHtml or http://192.168.0.117:8080/prod2test/helloWorld the first request after a rebuild/redeploy (we use a request filter and I can see the request hitting the filter) returns a 200 OK but the jsp that is displayed is the jsp that is displayed when the request failed to pass the filter requirements. Subsequent requests return a 404, not found error and I can see the request never hits the filter after that first request. Additional notes. 1. I am attempting to add this service to an existing application that is quite large because, at some time in the not too distant future, the entire application will be changed to run as a sevice so the client and server sides can be decoupled. 2. I have successfully created/deployed/run a REST service using the NetBeans templates but it has no web.xml and uses the 'ApplicationConfig' process to expose the service. If anyone has any ideas, I would certainly appreciate them. Thanks, Carl - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: JVM Crash in tcnative due to concurrency/timing in HTTP/2
On 13/06/17 10:13, Kreuser, Peter wrote: > Mark, > >> On 09/06/17 16:02, Kreuser, Peter wrote: >>> Hi all, >>> >>> Sorry for the long text. I hope somebody can help me track down the problem >>> I'm facing with Tomcat (8.5.15), tcnative (1.2.12), openssl (1.1.0e) and >>> HTTP/2. JVM is zulu-8.21.0.1 (1.8.0_131-b11) >> >> No need to apologise. There was enough information in this report for me >> to be 95% sure of what was going on before I tested things locally. >> >> >> >>> Would be nice if somebody here could tell me if that is a bug or if I have >>> some misconfiguration. >> >> It is a bug. >> >> The short explanation is that with NIO2, the style of the API (async >> read/write with CompletionHandlers) means that a TLS connection can get >> closed down (by a CompletionHandler) before the access log entry is >> written. This leads to passing a NULL reference to some native code >> which - unsurprisingly - falls over (Tomcat is meant to make sure it >> doesn't pass NULL references). >> >> There is an easy fix but the side-effect is that sometimes the cipher >> suite name won't appear in the access log. Depending on timing on your >> system that could be very frequent to almost never. I'd roughly expect >> it to happen as frequently as the crashes. >> >> The harder fix is to note that we want the info and to ensure we cache >> it before the TLS connection is closed down. In theory, we could do this >> in the access log but it means parsing the request attribute config. >> Performance wise, there will be an impact on users since the lookup to >> populate the cache will occur during request processing rather than >> afterwards. However, overall throughput should be unaffected. >> >> An alternative fix is for the application to trigger the caching of the >> TLS info by requesting one of the TLD attributes. >> >> Switching to NIO should also fix this. Note, I would not expect NIO and >> NIO2 to be much different performance wise. >> >> Would the easy fix be sufficient? >> >> Mark > > For a start the easy fix would be sufficient. Apparently this is only a real > problem when I call the site via curl, as it does not happen in the various > browsers (at least not on every call). > > We should at least make users aware that certain information can be missing > in the accesslog and the cause of it (in the AccessLogValve documentation?). > And are there any other implications of the asynchronicity? I guess the > behavior of NIO2 and HTTP/2 processing is not obvious? > > Your alternative fix would be to copy the attributes during request > processing (in a filter) and then log them from the filter request attributes > instead of the predefined ssl attributes? Correct? > > Thank you for your support and the bug fix ;-)! Have you filed the bug > internally or should I? I need to look into this some more first. Remy's comments suggest that my first analysis might have been wrong. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7, null tag attributes
On Tue, Jun 6, 2017 at 2:29 PM, Mark Thomas wrote: > On 31/05/17 23:31, Chris Cheshire wrote: > > I am using tomcat 7 on CentOS 7 and I need to pass a null value to tag > > attributes of type Long/Integer/Float, however it is *always* coerced to > > zero. > > > > <%@attribute name="parentId" required="true" rtexprvalue="true" > > type="java.lang.Long" %> > > > > Changing required to false does nothing. I tried setting the system > > property org.apache.el.parser.COERCE_TO_ZERO to false in tomcat.conf > > (-Dorg.apache.el.parser.COERCE_TO_ZERO=false with my other JAVA_OPTS) > but > > this does nothing. > > As expected. That system property only affects evaluation of EL > expressions. > > But isn't evaluation of an EL expression? Why is it treated differently than the evaluation of ${val} when it is used in the same scope as it is declared/assigned? For instance, this tests in a JSP : l is null will succeed. The moment I pass l into a tag and try the exact same evaluation inside, it fails because it has been coerced to 0. > > > How do I pass a null Long/Float/Integer as a tag attribute and have it > kept > > as null and not turned into an incorrect value? > > Use parentId="<%=null%>" rather than parentId="" > > Ugly, but it does the job. Scriplets aren't coerced. > > Mark > I can't use that because I'm not trying to pass the value null, rather a variable that possibly equates to null. Also, if I have a custom bean public class Foo { private Long val; public Foo() { } public Long getVal() { return val; } public void setVal(Long val) { this.val = val; } } and I pass an instance of Foo into a tag, then val stays as null. It seems the only solutions are to use a sentinel value that "shouldn't" get used (cringeworthy in its own right), or to wrap everything in a custom bean (also extremely ugly). I'm bewildered at why tomcat operates this way when it comes to Numbers and Strings. Why is it insistent on coercion when null and zero are absolutely not the same value. If this is because of autoboxing, then isn't that a bug? A long is not a Long, and when tag attributes must be objects and not atomic types, shouldn't they be treated accordingly? Chris
RE: tomcat 7, null tag attributes
All, As of now we are using the below parameters for tomcat8 version on production environment, please recheck and confirm, these are fine or anything need to add or change. Please confirm me. export CATALINA_OPTS="$CATALINA_OPTS -Xms1024m" export CATALINA_OPTS="$CATALINA_OPTS -Xmx8192m" export CATALINA_OPTS="$CATALINA_OPTS -server" export JAVA_OPTS="$JAVA_OPTS -Xverify:none" export CATALINA_OPTS="$CATALINA_OPTS -XX:+TieredCompilation -XX:+AggressiveOpts -XX:+UseG1GC -XX:SurvivorRatio=1 -XX:NewRatio=2 -XX:MaxTenuringThreshold=15 -XX:+UseTLAB -XX:G1HeapRegionSize=32m -XX:-UseAdaptiveSizePolicy -XX:MaxMetaspaceSize=512m -XX:-UseSplitVerifier " -Original Message- From: Chris Cheshire [mailto:yahoono...@gmail.com] Sent: Tuesday, June 13, 2017 7:58 PM To: Tomcat Users List Subject: Re: tomcat 7, null tag attributes On Tue, Jun 6, 2017 at 2:29 PM, Mark Thomas wrote: > On 31/05/17 23:31, Chris Cheshire wrote: > > I am using tomcat 7 on CentOS 7 and I need to pass a null value to > > tag attributes of type Long/Integer/Float, however it is *always* > > coerced to zero. > > > > <%@attribute name="parentId" required="true" rtexprvalue="true" > > type="java.lang.Long" %> > > > > Changing required to false does nothing. I tried setting the system > > property org.apache.el.parser.COERCE_TO_ZERO to false in tomcat.conf > > (-Dorg.apache.el.parser.COERCE_TO_ZERO=false with my other > > JAVA_OPTS) > but > > this does nothing. > > As expected. That system property only affects evaluation of EL > expressions. > > But isn't evaluation of an EL expression? Why is it treated differently than the evaluation of ${val} when it is used in the same scope as it is declared/assigned? For instance, this tests in a JSP : l is null will succeed. The moment I pass l into a tag and try the exact same evaluation inside, it fails because it has been coerced to 0. > > > How do I pass a null Long/Float/Integer as a tag attribute and have > > it > kept > > as null and not turned into an incorrect value? > > Use parentId="<%=null%>" rather than parentId="" > > Ugly, but it does the job. Scriplets aren't coerced. > > Mark > I can't use that because I'm not trying to pass the value null, rather a variable that possibly equates to null. Also, if I have a custom bean public class Foo { private Long val; public Foo() { } public Long getVal() { return val; } public void setVal(Long val) { this.val = val; } } and I pass an instance of Foo into a tag, then val stays as null. It seems the only solutions are to use a sentinel value that "shouldn't" get used (cringeworthy in its own right), or to wrap everything in a custom bean (also extremely ugly). I'm bewildered at why tomcat operates this way when it comes to Numbers and Strings. Why is it insistent on coercion when null and zero are absolutely not the same value. If this is because of autoboxing, then isn't that a bug? A long is not a Long, and when tag attributes must be objects and not atomic types, shouldn't they be treated accordingly? Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] tomcat 7, null tag attributes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Naga, Please don't hijack threads. If you wish to ask a question, please post a new message (don't REPLY to an old one) to the list. Thanks, - -chris On 6/13/17 1:00 PM, Naga Ramesh wrote: > All, > > As of now we are using the below parameters for tomcat8 version on > production environment, please recheck and confirm, these are fine > or anything need to add or change. > > Please confirm me. > > export CATALINA_OPTS="$CATALINA_OPTS -Xms1024m" export > CATALINA_OPTS="$CATALINA_OPTS -Xmx8192m" export > CATALINA_OPTS="$CATALINA_OPTS -server" export > JAVA_OPTS="$JAVA_OPTS -Xverify:none" export > CATALINA_OPTS="$CATALINA_OPTS -XX:+TieredCompilation > -XX:+AggressiveOpts -XX:+UseG1GC -XX:SurvivorRatio=1 -XX:NewRatio=2 > -XX:MaxTenuringThreshold=15 -XX:+UseTLAB -XX:G1HeapRegionSize=32m > -XX:-UseAdaptiveSizePolicy -XX:MaxMetaspaceSize=512m > -XX:-UseSplitVerifier " > > > > -Original Message- From: Chris Cheshire > [mailto:yahoono...@gmail.com] Sent: Tuesday, June 13, 2017 7:58 PM > To: Tomcat Users List Subject: Re: tomcat 7, null tag attributes > > On Tue, Jun 6, 2017 at 2:29 PM, Mark Thomas > wrote: > >> On 31/05/17 23:31, Chris Cheshire wrote: >>> I am using tomcat 7 on CentOS 7 and I need to pass a null >>> value to tag attributes of type Long/Integer/Float, however it >>> is *always* coerced to zero. >>> >>> <%@attribute name="parentId" required="true" rtexprvalue="true" >>> type="java.lang.Long" %> >>> >>> Changing required to false does nothing. I tried setting the >>> system property org.apache.el.parser.COERCE_TO_ZERO to false >>> in tomcat.conf (-Dorg.apache.el.parser.COERCE_TO_ZERO=false >>> with my other JAVA_OPTS) >> but >>> this does nothing. >> >> As expected. That system property only affects evaluation of EL >> expressions. >> >> > But isn't evaluation of an EL > expression? Why is it treated differently than the evaluation of > ${val} when it is used in the same scope as it is > declared/assigned? > > For instance, this tests in a JSP : > > l is null > > will succeed. > > The moment I pass l into a tag and try the exact same evaluation > inside, it fails because it has been coerced to 0. > > >> >>> How do I pass a null Long/Float/Integer as a tag attribute and >>> have it >> kept >>> as null and not turned into an incorrect value? >> >> Use parentId="<%=null%>" rather than parentId="" >> >> Ugly, but it does the job. Scriplets aren't coerced. >> >> Mark >> > > > I can't use that because I'm not trying to pass the value null, > rather a variable that possibly equates to null. > > Also, if I have a custom bean > > public class Foo { private Long val; > > public Foo() { } public Long getVal() { return val; } public void > setVal(Long val) { this.val = val; } } > > and I pass an instance of Foo into a tag, then val stays as null. > > It seems the only solutions are to use a sentinel value that > "shouldn't" get used (cringeworthy in its own right), or to wrap > everything in a custom bean (also extremely ugly). > > I'm bewildered at why tomcat operates this way when it comes to > Numbers and Strings. Why is it insistent on coercion when null and > zero are absolutely not the same value. If this is because of > autoboxing, then isn't that a bug? A long is not a Long, and when > tag attributes must be objects and not atomic types, shouldn't > they be treated accordingly? > > > Chris > > > - > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZQCtVAAoJEBzwKT+lPKRYqm0QAIC1onD6dKSqA8FBiD2hfSF+ fGM2hQ6j7nWQPQXT8DogrreL8Dhc2u0RU6jllMBh1mMuYOpLa51iWZz3MQpS6bx1 28CcwlHpb04TH4FBzan1a1ENxwWGFqrpzx4tltRmZy6LHi2/ElNcljMIfOcKBE53 qMSUxH8erBamRwXliYBKlTuTNzLdkhqC2tJ3eWwJ4m8vdXg2zHZ9R3crSBqUZB4y NoiOMnr4LO8NMJJp1obI27fLsBf6CnYPSPYFzjqPoXCSe+gk7E0VG47+MOEl2l/K Yu4ZrkmFqsPlwoSjrKuQVcsvERKb8vxJKn9180UweI2WVgzuxhJLUjtuXzjsat6O hyhQk623a33chKmpK9KJV1t2c5p/MzrPqBf+ZoOUHeXUWtwHA/QHqDWxvs4t/9+k UPYy0PxrNLu29UzbRDXuc0CRXq463jHyA/UpnJano35lc5sIKeJb12LijHcvxNfT 5GgGGIHFzM7NEW3TAXzwkSWofGK2lri99qYU+/IJOA8L+1QLFhnn1JEXHsgJXeRs XwP/6VQJv4gupOSk9V3LVfztmlY9H/y+Rba0pMqqj/qulo6QJ4rRhykFrX79KFXr cnCzJsBOzxyN+mz9XHwPYluQaCTRfYz1OnEeWKaOs1L9Fi+ZC0oCjiWRE2KM8IwD 4deH3ritpTrr5PDGaKyX =ZZuh -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AsynContext.dispatch() with encoded URI
hi, The spec says: "If the AsyncContext was initialized via the startAsync(ServletRequest, ServletResponse) and the request passed is an instance of HttpServletRequest , then the dispatch is to the URI returned by HttpServletRequest.getRequestURI()" However AsyncContextImpl seems to be using the servletPath: https://github.com/apache/tomcat/blob/9af8708d7ea3817df47f34146a6ff802d96980fa/java/org/apache/catalina/core/AsyncContextImpl.java#L156-L163 So given a URL with an encoded slash (and UDecoder.ALLOW_ENCODED_SLASH=true): /foo/vv%2F1234/add/2 The dispatch ends up going to: /foo/vv/1234/add/2 Is this intentional? It contradicts the spec. Thanks, Rossen
Re: tomcat 7, null tag attributes
On 13/06/17 15:27, Chris Cheshire wrote: > On Tue, Jun 6, 2017 at 2:29 PM, Mark Thomas wrote: > >> On 31/05/17 23:31, Chris Cheshire wrote: >>> I am using tomcat 7 on CentOS 7 and I need to pass a null value to tag >>> attributes of type Long/Integer/Float, however it is *always* coerced to >>> zero. >>> >>> <%@attribute name="parentId" required="true" rtexprvalue="true" >>> type="java.lang.Long" %> >>> >>> Changing required to false does nothing. I tried setting the system >>> property org.apache.el.parser.COERCE_TO_ZERO to false in tomcat.conf >>> (-Dorg.apache.el.parser.COERCE_TO_ZERO=false with my other JAVA_OPTS) >> but >>> this does nothing. >> >> As expected. That system property only affects evaluation of EL >> expressions. >> >> > But isn't evaluation of an EL expression? Why is > it treated differently than the evaluation of ${val} when it is used in the > same scope as it is declared/assigned? > > For instance, this tests in a JSP : > > > l is null value in the set tag has the type object doesn't it? That would explain the lack of coercion. > > will succeed. > > The moment I pass l into a tag and try the exact same evaluation inside, it > fails because it has been coerced to 0. > > >> >>> How do I pass a null Long/Float/Integer as a tag attribute and have it >> kept >>> as null and not turned into an incorrect value? >> >> Use parentId="<%=null%>" rather than parentId="" >> >> Ugly, but it does the job. Scriplets aren't coerced. >> >> Mark >> > > > I can't use that because I'm not trying to pass the value null, rather a > variable that possibly equates to null. > > Also, if I have a custom bean > > public class Foo { > private Long val; > > public Foo() { } > public Long getVal() { return val; } > public void setVal(Long val) { this.val = val; } > } > > and I pass an instance of Foo into a tag, then val stays as null. > > It seems the only solutions are to use a sentinel value that "shouldn't" > get used (cringeworthy in its own right), or to wrap everything in a custom > bean (also extremely ugly). > > I'm bewildered at why tomcat operates this way when it comes to Numbers and > Strings. Why is it insistent on coercion when null and zero are absolutely > not the same value. If this is because of autoboxing, then isn't that a > bug? A long is not a Long, and when tag attributes must be objects and not > atomic types, shouldn't they be treated accordingly? Tomcat behaves this way because the specification says it has to. Plenty of folks disagree strongly with the specification but Tomcat has to implement it. COERCE_TO_ZERO is a specification breaking configuration option to workaround this particular behaviour. I've been digging in to this some more and it appears that COERCE_TO_ZERO has been given a wider scope in later versions of Tomcat. The test case you present above behaves the way you want with COERCE_TO_ZERO set to false in 8.0.x and above. I need to dig into why that wider scope wasn't applied to 7.0.x. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7, null tag attributes
On 13/06/17 22:01, Mark Thomas wrote: > On 13/06/17 15:27, Chris Cheshire wrote: >> I'm bewildered at why tomcat operates this way when it comes to Numbers and >> Strings. Why is it insistent on coercion when null and zero are absolutely >> not the same value. If this is because of autoboxing, then isn't that a >> bug? A long is not a Long, and when tag attributes must be objects and not >> atomic types, shouldn't they be treated accordingly? > > Tomcat behaves this way because the specification says it has to. Plenty > of folks disagree strongly with the specification but Tomcat has to > implement it. COERCE_TO_ZERO is a specification breaking configuration > option to workaround this particular behaviour. > > I've been digging in to this some more and it appears that > COERCE_TO_ZERO has been given a wider scope in later versions of Tomcat. > The test case you present above behaves the way you want with > COERCE_TO_ZERO set to false in 8.0.x and above. I need to dig into why > that wider scope wasn't applied to 7.0.x. Mystery solved thanks to some svn archaeology and cross-referencing to the relevant specs. Tomcat 7 implements EL 2.2. EL 2.2 requires coercion of "" and null to 0 for numeric types (section 1.18.3). (As did earlier versions of the EL spec). Initially there weren't many complaints because the coercion rules weren't implemented correctly in one important case (i.e. they left these as null rather than coercing to zero). Then bug 43285 [1] got fixed and the complaints started. To address the complaints, Tomcat introduced the system property org.apache.el.parser.COERCE_TO_ZERO which restored the non-specification compliant behaviour for the one coercion case that was causing problems. To align with the EL 2.2. specification, the default was for coercion to zero to occur. The level of complaints about the coercion rules was such that a backwards compatible change was introduced in EL 3.0 to not coerce to zero. Given Java EE's normal approach that backwards compatibility concerns trump all others, it is a sign of the seriousness with which the issue was taken that an incompatible change was made. Tomcat 8, which implemented EL 3.0, switched to the new coercion rules. To help migration of 7.0.x applications, the role of COERCE_TO_ZERO was expanded to cover all instances of EL coercion. To align with EL 3.0, the default was changed not to coerce to zero. Which brings us to where we are today. The problem you are seeing is a spec compliant coercion that is not covered by the COERCE_TO_ZERO property in 7.0.x. There are several possible solutions: 1. Upgrade to 8.x (8.5.x recommended in preference to 8.0.x) I appreciate that an RPM is not available for Tomcat 8 but 8.0.x has had stable releases for three years and 8.5.x for 1 year. 2. Use one of the workarounds. All pretty ugly. 3. Lobby for the extension of scope for COERCE_TO_ZERO in 7.0.x to be equivalent to the scope in 8.0.x. At this stage in the 7.0.x that is unlikely to happen. The risk of breakage for other users is too great. 4. Lobby for an additional configuration option for 7.0.x that extends the of scope for COERCE_TO_ZERO in 7.0.x to be equivalent to the scope in 8.0.x. This should be doable with care (there was some refactoring involved in the scope change that would need careful back-porting). This is also dependent on the CentOS distribution picking up the change to 7.0.x. I don't know how likely that is. Given the current package is based on a version over a year old I suspect that the changes of this being quick are very low. None of those options look ideal. I'd probably go with 1 but my familiarity with Tomcat is such that I usually prefer to work with an ASF distribution rather than a downstream one anyway. YMMV. Mark [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43285 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AsynContext.dispatch() with encoded URI
On 13/06/17 21:30, Rossen Stoyanchev wrote: > hi, > > The spec says: > > "If the AsyncContext was initialized via the startAsync(ServletRequest, > ServletResponse) and the request passed is an instance of > HttpServletRequest , then the dispatch is to the URI returned by > HttpServletRequest.getRequestURI()" > > However AsyncContextImpl seems to be using the servletPath: > https://github.com/apache/tomcat/blob/9af8708d7ea3817df47f34146a6ff802d96980fa/java/org/apache/catalina/core/AsyncContextImpl.java#L156-L163 > > So given a URL with an encoded slash (and > UDecoder.ALLOW_ENCODED_SLASH=true): > /foo/vv%2F1234/add/2 > > The dispatch ends up going to: > /foo/vv/1234/add/2 > > Is this intentional? It contradicts the spec. The commit that introduced this change is: https://svn.apache.org/viewvc?view=revision&revision=1497474 The fix to ServletRequest.getContextPath() was made a little later: https://svn.apache.org/viewvc?view=revision&revision=1593621 This looks like a fairly minor bug that should be an easy fix. Please open a bugzilla issue for this. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AsynContext.dispatch() with encoded URI
Issue created https://bz.apache.org/bugzilla/show_bug.cgi?id=61185. On Tue, Jun 13, 2017 at 6:25 PM, Mark Thomas wrote: > On 13/06/17 21:30, Rossen Stoyanchev wrote: > > hi, > > > > The spec says: > > > > "If the AsyncContext was initialized via the startAsync(ServletRequest, > > ServletResponse) and the request passed is an instance of > > HttpServletRequest , then the dispatch is to the URI returned by > > HttpServletRequest.getRequestURI()" > > > > However AsyncContextImpl seems to be using the servletPath: > > https://github.com/apache/tomcat/blob/9af8708d7ea3817df47f34146a6ff8 > 02d96980fa/java/org/apache/catalina/core/AsyncContextImpl.java#L156-L163 > > > > So given a URL with an encoded slash (and > > UDecoder.ALLOW_ENCODED_SLASH=true): > > /foo/vv%2F1234/add/2 > > > > The dispatch ends up going to: > > /foo/vv/1234/add/2 > > > > Is this intentional? It contradicts the spec. > > The commit that introduced this change is: > https://svn.apache.org/viewvc?view=revision&revision=1497474 > > The fix to ServletRequest.getContextPath() was made a little later: > https://svn.apache.org/viewvc?view=revision&revision=1593621 > > This looks like a fairly minor bug that should be an easy fix. Please > open a bugzilla issue for this. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
IPV6
Hello I am having below query for tomcat 8.5.15 version. Please help. I am using tomcat 8.5.15 and my network is supporting both ipv4 and ipv6 address stacks. However, I want tomcat to listen to only ipv6 address (not ipv4). I was trying to find the solution on google and reached to tomcat's manual - http://library.bec.ac.in/docs/config/http.html. On this page, the address attribute description says ---> For servers with more than one IP address, this attribute specifies which address will be used for listening on the specified port. By default, the connector will listen all local addresses. Unless the JVM is configured otherwise using system properties, the Java based connectors (NIO, NIO2) will listen on both IPv4 and IPv6 addresses when configured with either 0.0.0.0 or ::. The APR/native connector will only listen on IPv4 addresses if configured with 0.0.0.0 and will listen on IPv6 addresses (and optionally IPv4 addresses depending on the setting of ipv6onlyv6) if configured with ::. According to above description, with the use of ipv6onlyv6, tomcat will listen only on ipv6 address, I tried below combination -- ** Above combination worked flawlessly in windows machine. but when I am using the combination in linux suse, it's not working. This combination is not blocking ipv4 address stack, in linux suse. Tomcat is listening to both ipv6 and ipv4 address stacks. Below is linux system details (via uname -a) -- Linux ip-10-1-29-39.ec2.internal 3.12.49-1-default #1 SMP Fri Dec 11 11:36:56 UTC 2015 (6571a4b) x86_64 x86_64 x86_64 GNU/Linux