[Bug 53952] Add support for TLS 1.1 and 1.2
https://issues.apache.org/bugzilla/show_bug.cgi?id=53952
--- Comment #17 from Marcel Šebek ---
The problem is following. OpenSSL 0.9.8y defines SSL_OP_PKCS1_CHECK_{1,2} as
0x0800L and 0x1000L while OpenSSL 1.0.1e uses the same values for
SSL_OP_NO_TLSv1_{1,2}, and defines SSL_OP_PKCS1_CHECK_{1,2} as zero. Therefore,
java code calling hasOp with SSL_OP_NO_TLSv1_{1,2} succeeds against both 0.9.8
and 1.0.1. I see no perfect solution, but quite a good way to overcome this
issue is to drop SSL_OP_PKCS1_CHECK_* from supported_ssl_opts. Then, these OP's
cannot be tested via hasOp, but the flags seem to be unused anyway, according
to the comment in 1.0.1e:
/* These next two were never actually used for anything since SSLeay
* zap so we have some more flags.
*/
I'll send fixed patches in a moment. They have been tested (with JBoss, as
before) against both 0.9.8y and 1.0.1e. I've also tested newer java against old
tcnative, and it works correctly (enabling one of the newer protocols causes a
failure).
--
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 53952] Add support for TLS 1.1 and 1.2
https://issues.apache.org/bugzilla/show_bug.cgi?id=53952 --- Comment #18 from Marcel Šebek --- Created attachment 30149 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30149&action=edit patch dropping SSL_OP_PKCS* from supported_ssl_opts -- 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 53952] Add support for TLS 1.1 and 1.2
https://issues.apache.org/bugzilla/show_bug.cgi?id=53952 Marcel Šebek changed: What|Removed |Added Attachment #30111|0 |1 is obsolete|| --- Comment #19 from Marcel Šebek --- Created attachment 30150 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30150&action=edit Patch for tomcat native adding support for newer TLS versions -- 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 54800] New: Possible thread/memory leak with use of WebSocketContainer
https://issues.apache.org/bugzilla/show_bug.cgi?id=54800 Bug ID: 54800 Summary: Possible thread/memory leak with use of WebSocketContainer Product: Tomcat 8 Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: rstoyanc...@yahoo.com Classification: Unclassified Whenever WebSocketContainer is used to connect to a server endpoint, the following message appears when Tomcat shuts down: SEVERE: The web application [/websocket-test] appears to have started a thread named [Thread-4] but has failed to stop it. This is very likely to create a memory leak. The message is repeated for 6 different threads. I don't have proof this is caused by the use of WebSocketContainer but the messages don't appear when it isn't used. The Endpoint used to connect is very simple. It sends a message when the session is opened to the EchoEndpoint on the server side, and prints the response and closes when the message is echoed back. -- 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 54801] New: EL-like expressions in jsp:scriptlet break compilation of tag files using XML syntax
https://issues.apache.org/bugzilla/show_bug.cgi?id=54801
Bug ID: 54801
Summary: EL-like expressions in jsp:scriptlet break compilation
of tag files using XML syntax
Product: Tomcat 7
Version: 7.0.39
Hardware: PC
OS: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
Assignee: dev@tomcat.apache.org
Reporter: knst.koli...@gmail.com
Classification: Unclassified
Created attachment 30152
--> https://issues.apache.org/bugzilla/attachment.cgi?id=30152&action=edit
helloWorld.tagx
Steps to reproduce:
1. Go to webapps\examples\WEB-INF\tags\
2. Delete "helloWorld.tag" file and put there "helloWorld.tagx" file attached
to this issue.
The file contains the following plus AL header:
http://java.sun.com/JSP/Page"; version="2.0">
3. Start Tomcat and try to open the following page in a browser:
http://localhost:8080/examples/jsp/jsp2/tagfiles/hello.jsp
ACTUAL result:
in current TC8 trunk:
org.xml.sax.SAXException: Body of scriptlet element must not contain any XML
elements
org.apache.jasper.compiler.JspDocumentParser.checkScriptingBody(JspDocumentParser.java:1332)
org.apache.jasper.compiler.JspDocumentParser.endElement(JspDocumentParser.java:650)
This behaviour is caused by "${foo}" being present inside the scriptlet. If I
remove that line, the page is displayed successfully.
EXPECTED RESULT
I think EL expressions should not be recognized inside of jsp:scriptlet,
jsp:declaration or jsp:expression and should not trigger such an error.
As a confirmation, the following "helloWorld.tag" in JSP syntax compiles and
executes successfully. Thus this issue is with XML syntax only,
<%
// ${foo}
%>
Hello, world!++
Alternative solution could be to change the error message, but I think it is
not the issue here,
s/ any XML elements / any XML elements or EL expressions/
--
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 54801] EL-like expressions in jsp:scriptlet break compilation of tag files using XML syntax
https://issues.apache.org/bugzilla/show_bug.cgi?id=54801 --- Comment #1 from Konstantin Kolinko --- Created attachment 30153 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30153&action=edit Stacktrace (current 7.0 = 7.0.39) -- 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 54802] New: Provide location information for exceptions thrown by JspDocumentParser
https://issues.apache.org/bugzilla/show_bug.cgi?id=54802 Bug ID: 54802 Summary: Provide location information for exceptions thrown by JspDocumentParser Product: Tomcat 7 Version: 7.0.39 Hardware: PC OS: Windows XP Status: NEW Severity: enhancement Priority: P2 Component: Jasper Assignee: dev@tomcat.apache.org Reporter: knst.koli...@gmail.com Classification: Unclassified Steps to reproduce - see bug 54801 It causes an exception to be thrown by org.apache.jasper.compiler.JspDocumentParser.checkScriptingBody() The issue is that the exception in bug 54801 does not provide any information on the file where it occurred. It does not show in which tag file it happened, and thus it is hard to follow. There are four places in JspDocumentParser where it throws a "SAXException" without any location information. I propose to replace throw new SAXException(msg); with throw new SAXParseException(msg, locator); I am not sure that line numbers will be correct in all four cases, but at least it will provide the name of the file. This is better than nothing. -- 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 54802] Provide location information for exceptions thrown by JspDocumentParser
https://issues.apache.org/bugzilla/show_bug.cgi?id=54802 --- Comment #1 from Konstantin Kolinko --- Created attachment 30154 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30154&action=edit Text of Error page shown for bug 54801 by current trunk Text of error page. The tag file name is nowhere to be found. In the "localhost.date.log" file only the inner org.xml.sax.SAXException is printed. The outer ones are shown by the error page only. -- 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
svn commit: r1464781 - /tomcat/trunk/java/org/apache/jasper/compiler/JspDocumentParser.java
Author: kkolinko
Date: Thu Apr 4 23:00:53 2013
New Revision: 1464781
URL: http://svn.apache.org/r1464781
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=54802
Provide location information for exceptions thrown by JspDocumentParser
Modified:
tomcat/trunk/java/org/apache/jasper/compiler/JspDocumentParser.java
Modified: tomcat/trunk/java/org/apache/jasper/compiler/JspDocumentParser.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/JspDocumentParser.java?rev=1464781&r1=1464780&r2=1464781&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/JspDocumentParser.java
(original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/JspDocumentParser.java Thu Apr
4 23:00:53 2013
@@ -1184,8 +1184,9 @@ class JspDocumentParser
TagInfo tagInfo = tagLibInfo.getTag(localName);
TagFileInfo tagFileInfo = tagLibInfo.getTagFile(localName);
if (tagInfo == null && tagFileInfo == null) {
-throw new SAXException(
-Localizer.getMessage("jsp.error.xml.bad_tag", localName, uri));
+throw new SAXParseException(
+Localizer.getMessage("jsp.error.xml.bad_tag", localName, uri),
+locator);
}
Class tagHandlerClass = null;
if (tagInfo != null) {
@@ -1194,11 +1195,11 @@ class JspDocumentParser
tagHandlerClass =
ctxt.getClassLoader().loadClass(handlerClassName);
} catch (Exception e) {
-throw new SAXException(
+throw new SAXParseException(
Localizer.getMessage("jsp.error.loadclass.taghandler",
handlerClassName,
qName),
-e);
+locator, e);
}
}
@@ -1329,7 +1330,7 @@ class JspDocumentParser
Localizer.getMessage(
"jsp.error.parse.xml.scripting.invalid.body",
elemType);
-throw new SAXException(msg);
+throw new SAXParseException(msg, locator);
}
}
}
@@ -1357,7 +1358,7 @@ class JspDocumentParser
locator,
fnfe);
} catch (Exception e) {
-throw new SAXException(e);
+throw new SAXParseException(e.getMessage(), locator, e);
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54802] Provide location information for exceptions thrown by JspDocumentParser
https://issues.apache.org/bugzilla/show_bug.cgi?id=54802 --- Comment #2 from Konstantin Kolinko --- Created attachment 30155 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30155&action=edit Text of Error page shown for bug 54801 by trunk with r1464781 Fixed in trunk by r1464781 Here is what is now displayed by the error page. The "localhost.date.log" contains the same JasperException as shown by error page. The good point is that the message includes the file name, as desired. The bad point is that the original SAXParseException and its stack trace are not displayed and are not logged. The "JspDocumentParser.checkScriptingBody()" method where the original exception were thrown is not mentioned. -- 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
buildbot success in ASF Buildbot on tomcat-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/4200 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1464781 Blamelist: kkolinko Build succeeded! sincerely, -The Buildbot
DefaultServlet HttpServletResponse.setContentType called after HttpServletResponse.getOutputStream
In the DefaultServlet the content type is determined before the call to getOutputStream and then header is set after the
call to getOutputStream, how logical is this? I think it should set the content type header before the first call to
getOutputStream so that the content type is exposed to the outputstream filters.
tomcat-7.0.39-src
19 package org.apache.catalina.servlets;
120 public class DefaultServlet
821 String contentType = cacheEntry.attributes.getMimeType();
822 if (contentType == null) {
823 contentType = getServletContext().getMimeType(cacheEntry.name);
824 cacheEntry.attributes.setMimeType(contentType);
825 }
872 if (serveContent) {
877 ostream = response.getOutputStream();
893 }
910 if ( (cacheEntry.context != null)
917 if (contentType != null) {
921 response.setContentType(contentType);
922 }
I detected this problem while writing an xsltc templates based xalan translet filter that intercepts the output stream
optionally based on the content type which [Ceteris paribus] is unavailable at the code site
HttpServletRequestWrapper.getOutputStream.
I think the header could be set before line 877 , but I don't fully understand where cacheEntry.context happens and
other implications. I can make the patch to DefaultServlet.java but wanted to know if there are any other considerations?
Additionally, as a side note I see there is XSLT for directory listings, I
propose that listings get a
processing instruction and then served by the caching
translet caching filter which will be much faster, I will submit this under ASF2 if there is interest?
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
