[Bug 60461] SIGSEGV in SSLSocket.getInfos
https://bz.apache.org/bugzilla/show_bug.cgi?id=60461 Ludovic Pénet changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from Ludovic Pénet --- Reopening, following mattcoz comment. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60764] SlowQueryReport causing connection leak
https://bz.apache.org/bugzilla/show_bug.cgi?id=60764 --- Comment #3 from Keiichi Fujino --- Thanks. I am planning to fix this problem as follows. -Implement equals() and hashCode() in the StatementDecoratorInterceptor. -Enable StatementDecoratorInterceptor by default.(mybe configuable) As a result, Interceptor chain will be follows. DisposableConnectionFacade -> StatementDecoratorInterceptor -> XXXInterceptor(1..n) -> ProxyConnection -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57665] support x-forwarded-host
https://bz.apache.org/bugzilla/show_bug.cgi?id=57665 Balasubramanian changed: What|Removed |Added CC||ramarbalasubramanian@gmail. ||com --- Comment #5 from Balasubramanian --- (In reply to Stefan Fussenegger from comment #4) > The patch adds support for a hostHeader that works analogue to the existing > portHeader. It's disabled by default, keeping backward compatibility. > Setting it to a value like X-Forwarded-Host will override the value returned > by ServletRequest.getServerName() In which version of tomcat, this fix is available? I did not see this fix in tomcat 9 and 8. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60802] New: javax.servlet.http.Path javadoc isn't synced with final Servlet 3.1 standard
https://bz.apache.org/bugzilla/show_bug.cgi?id=60802 Bug ID: 60802 Summary: javax.servlet.http.Path javadoc isn't synced with final Servlet 3.1 standard Product: Tomcat 8 Version: 8.5.0 Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Specification APIs Assignee: dev@tomcat.apache.org Reporter: joak...@apache.org Target Milestone: The Tomcat specific javadoc for Servlet 3.1 is not synced with the official Servlet spec 3.1 properly. See https://github.com/apache/tomcat85/blob/trunk/java/javax/servlet/http/Part.java#L88-L90 The official spec says ... http://docs.oracle.com/javaee/7/api/javax/servlet/http/Part.html#write-java.lang.String- The use of Part.write(String) is always relative to the MultiPartConfig.location, its never absolute. Issue https://bz.apache.org/bugzilla/show_bug.cgi?id=54203 attempted to fix this. Resulting in commit https://github.com/apache/tomcat85/commit/073b311fd4f5650c68a0c61f9baf4d195775405a which looks like you pulled a draft version of the Part javadoc, not the official final version. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60802] javax.servlet.http.Path javadoc isn't synced with final Servlet 3.1 standard
https://bz.apache.org/bugzilla/show_bug.cgi?id=60802 --- Comment #1 from mgrigorov --- It is not just the javadoc. Also the behavior is different - when a File with an absolute path is passed it is used as is. When a file with relative path is passed then the config location is used as a parent. Honestly I do like this behavior! But I guess it should be removed since it is against the spec. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60802] javax.servlet.http.Path javadoc isn't synced with final Servlet 3.1 standard
https://bz.apache.org/bugzilla/show_bug.cgi?id=60802 Mark Thomas changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Mark Thomas --- Tomcat can't copy the Javadoc verbatim from the reference implementation due to licencing. It is different for the text the Sun contributed back when Tomcat was the reference implementation but that doesn't apply here. I don't see any text in the referenced Javadoc that says "The use of Part.write(String) is always relative to the MultiPartConfig.location, its never absolute." Where is this requirement coming from? My reading of the Javadoc is that Tomcat's implementation is spec compliant. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60802] javax.servlet.http.Path javadoc isn't synced with final Servlet 3.1 standard
https://bz.apache.org/bugzilla/show_bug.cgi?id=60802 --- Comment #3 from Joakim Erdfelt --- Glassfish, Resin, and Jetty implement it according to the javadoc. It's always relative to the MultiPartConfig.location Glassfish calls that location 'repository' see PartItem.java Jetty calls that location `_tmpDir` see MultiPartInputStreamParser.MultiPart Resin calls that location `location` see HttpServletRequestImpl.PartImpl Undertow implements it according to your interpretation (they seem to have followed your lead). The official servlet spec 3.1 final pdf also makes no statement on the behavior of that method. Only that the MultiPartConfig.location must have a value, and it goes through the default value and how to interpret the setting that the user has provided. I have no access to the Servlet TCK to confirm the behavior in there. But seeing as Glassfish interprets it the same way as the javadoc, I would probably guess that the odds on the Glassfish/Resin/Jetty interpretation is the correct way. Perhaps this needs a SERVLET_SPEC jira issue opened on it? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60806] New: Problem with ServletContext replication
https://bz.apache.org/bugzilla/show_bug.cgi?id=60806 Bug ID: 60806 Summary: Problem with ServletContext replication Product: Tomcat 8 Version: 8.5.11 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Cluster Assignee: dev@tomcat.apache.org Reporter: asgill...@gmail.com Target Milestone: Environment: Apache Tomcat 8.5.11 OpenJDK Runtime Environment (build 1.8.0_121-b13) Centos 7.3 (64 bit) I have a two node Tomcat cluster (server1 & server2) with an Apache load balancer. Context replication is enabled with: in META-INF/context.xml, and in WEB-INF/web.xml. When I place an object in the server1 ServletContext I see the following error on server2: 02-Mar-2017 11:31:28.088 SEVERE [Tribes-Task-Receiver[Catalina-Channel]-3] org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived Unable to deserialize MapMessage. java.lang.ClassNotFoundException: com.pharmhos.merlin.jaas.AdUser at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:677) at org.apache.catalina.tribes.io.ReplicationStream.resolveClass(ReplicationStream.java:79) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1819) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1713) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1986) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:422) at org.apache.catalina.tribes.io.XByteBuffer.deserialize(XByteBuffer.java:558) at org.apache.catalina.tribes.tipis.AbstractReplicatedMap$MapMessage.value(AbstractReplicatedMap.java:1504) at org.apache.catalina.tribes.tipis.AbstractReplicatedMap$MapMessage.deserialize(AbstractReplicatedMap.java:1462) at org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived(AbstractReplicatedMap.java:649) at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:300) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:83) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:83) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:116) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:83) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:276) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:244) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:213) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:101) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) It appears that my AdUser object is being serialized on server1 but is not being deserialized on server2. The "AdUser" class exists within the web application under WEB-INF/classes but it looks like the org.apache.catalina.tribes.io.ReplicationStream is not finding the right class loader for the web app. According to : > This seems to ReplicatedContext's bug. > In the current code, the class loader is passed to ReplicationMap as Null. > It is necessary to call super.startInternal() before initializing the > ReplicationMap. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60461] SIGSEGV in SSLSocket.getInfos
https://bz.apache.org/bugzilla/show_bug.cgi?id=60461 Mark Thomas changed: What|Removed |Added Status|REOPENED|NEEDINFO --- Comment #11 from Mark Thomas --- Steps to reproduce please on a clean install of the latest release of any of the supported Tomcat versions (7.0.x, 8.0.x, 8.5.x, 9.0.x) and the latest Tomcat Native release (1.2.x). -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60461] SIGSEGV in SSLSocket.getInfos
https://bz.apache.org/bugzilla/show_bug.cgi?id=60461 --- Comment #12 from matt...@cacorp.com --- Unfortunately I have no idea what is causing it and I don't know how to reproduce it. I installed a fresh copy of 8.5.11 with tcnative 1.2.10 and then copied in my configuration files. It crashed only once since I installed it on the 27th. It had crashed 6 times in 8.5.6 since late November, but 3 of those were in the last week and I'm not sure what could have changed. I did install a new SSL certificate, but it seems to be working fine most of the time. I really wish I could be of more help. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60802] javax.servlet.http.Path javadoc isn't synced with final Servlet 3.1 standard
https://bz.apache.org/bugzilla/show_bug.cgi?id=60802 Mark Thomas changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Mark Thomas --- I thought this had been discussed a little before https://bz.apache.org/bugzilla/show_bug.cgi?id=54971#c3 >From (rather hazy) memory, the reason for that was that Commons File Upload allowed absolute paths and Tomcat allowing it here eased the migration path. I'll add that the spec doesn't say how to handle the application passing an absolute path. You could make the case that the behaviour is undefined and in that case and the container is free to do as it chooses. Equally, you could argue anything that isn't a relative file name is an error that should trigger an IOException. At the extreme, you could argue anything that isn't a pure filename with no path is an error. I don't see any discussion around this particular point in the Servlet EG. Now is certainly the time to open an issue if you'd like clarification since the EG is fairly active at the moment. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60761] Unable to re-use/extend NioEndpoint
https://bz.apache.org/bugzilla/show_bug.cgi?id=60761 --- Comment #1 from Amit Pande --- Any guidance on this? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60808] New: ServletRequest.getParameterMap() not fully immutable
https://bz.apache.org/bugzilla/show_bug.cgi?id=60808
Bug ID: 60808
Summary: ServletRequest.getParameterMap() not fully immutable
Product: Tomcat 8
Version: 8.5.x-trunk
Hardware: PC
OS: Mac OS X 10.1
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: woon...@apache.org
Target Milestone:
A corner case was discovered: if
request.getParameterMap().keySet().retainAll(set) is called even after the
internal ParameterMap is locked.
Reproducible step:
- Create a simple JSP page like this:
<%
// test.jsp
out.println("request.getParameterMap(): " + request.getParameterMap());
request.getParameterMap().keySet().retainAll(java.util.Collections.emptySet());
out.println("request.getParameterMap(): " + request.getParameterMap());
%>
- Request the page. e.g, http://localhost:8080/examples/test.jsp?p1=v1&p2=v2
- You will notice the second output is empty.
According to the javadoc of javax.servlet.ServletRequest#getParameterMap(), the
returned map must be immutable. But, its #keySet() seems to return a mutable
set. It could have returned an unmodifiable set at least like
Collections.unmodifiableMap(map) does.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] tomcat pull request #46: Bug_60808: ensure immutability of ParameterMap.
GitHub user woonsan opened a pull request: https://github.com/apache/tomcat/pull/46 Bug_60808: ensure immutability of ParameterMap. You can merge this pull request into a Git repository by running: $ git pull https://github.com/woonsan/tomcat bugfix/Bug_60808 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tomcat/pull/46.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #46 commit 5ec932ad2f3f5b2b178a345856e17b3a4eedd528 Author: Woonsan Ko Date: 2017-03-03T07:10:25Z Bug_60808: ensure immutability of ParameterMap. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60808] ServletRequest.getParameterMap() not fully immutable
https://bz.apache.org/bugzilla/show_bug.cgi?id=60808 --- Comment #1 from Woonsan Ko --- Patch available via PR: https://github.com/apache/tomcat/pull/46 Please review the PR. Thanks, Woonsan -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
