Re: View towards refactoring changes?
IIRC - there was talk of this over a year ago. In think in the context of that talk APR also had some duplication too and was "in scope" for the merge. But the dev list archives has more details and the conclusion. -Tim Kirk True wrote: Hi all, There are a number of places in NioEndpoint and JIoEndpoint that share a good portion of common code. The accessors for common properties take up a good chunk, but there's also some boilerplate code for checking if we're paused, running, etc. There are a lot of places where variable and method scope could be cleaned up too. Obviously I can't commit this code myself, but if I submitted patches for it, would they be looked upon favorably or ignored as noise? :) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46603] New: Cookies retrieved from tomcat server is not correct
https://issues.apache.org/bugzilla/show_bug.cgi?id=46603 Summary: Cookies retrieved from tomcat server is not correct Product: Tomcat 5 Version: 5.5.27 Platform: PC OS/Version: Windows Server 2003 Status: NEW Severity: normal Priority: P2 Component: Unknown AssignedTo: dev@tomcat.apache.org ReportedBy: carl.sky...@gmail.com Hi, we are using cookies to save user information. This information is encrypted and a cookie can look like this. "alsdnfonion32rasdlfkn==" When this cookies is retrieved from the Apache Tomcat server the last 2 characters is removed. This makes the decryption of the cookie impossible. This error is also found in the Apache Tomcat 5.5.26. It seems like the Tomcat cant handle the '=' characters in cookies. We have tested the 5.5.25 version of tomcat and in this version the cookie handling works fine. Br. Carl Skymne -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 46606] New: WebdavServlet
https://issues.apache.org/bugzilla/show_bug.cgi?id=46606
Summary: WebdavServlet
Product: Tomcat 6
Version: unspecified
Platform: All
URL: http://svn.apache.org/repos/asf/tomcat/trunk/java/org/ap
ache/catalina/servlets/WebdavServlet.java
OS/Version: All
Status: NEW
Keywords: RFC
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: robert.ja...@uniklinik-freiburg.de
In the Webdav standard, there is a header option named "depth".
This header must be given when running a propfind webdav request.
The value may be greater 0 or the constant "infinity", i.e. the
whole file tree is requested.
In the WebdavServlet, INFINITY is set to 3, which unfortunately
does not correspond to the standard.
>>> CODE >>>
/**
* Default depth is infite.
*/
private static final int INFINITY = 3; // To limit tree browsing a bit
<<< END OF CODE <<<
Perhaps this could be changed to a much higher value (e.g. maxint).
Below, there is a method named propfind, where the following code
can be found:
>>> CODE >>>
String depthStr = req.getHeader("Depth");
if (depthStr == null) {
depth = INFINITY;
} else {
if (depthStr.equals("0")) {
depth = 0;
} else if (depthStr.equals("1")) {
depth = 1;
} else if (depthStr.equals("infinity")) {
depth = INFINITY;
}
}
<<< END OF CODE <<<
Perhaps one should use an integer conversion function and in case
of an exception one could use infinity.
Hope this describes the problem good enough.
The same problem occurs in Tomcat 5.x, as well.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- 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
DO NOT REPLY [Bug 46607] New: java.lang.OutOfMemoryError on AIX6.1
https://issues.apache.org/bugzilla/show_bug.cgi?id=46607 Summary: java.lang.OutOfMemoryError on AIX6.1 Product: Tomcat 6 Version: 6.0.18 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: csant...@temenos.com Hi, we are testing out browser application deployment on tomcat 6.0.18 where we are gettinng java.lang.OutOfMemoryError in the logs and and we are unable to use tomcat. log details below, Jan 26, 2009 3:36:11 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet BrowserServlet threw exception java.lang.OutOfMemoryError at java.lang.String.(String.java:295) at org.apache.xerces.xni.XMLString.toString(Unknown Source) at org.apache.xerces.parsers.AbstractDOMParser.characters(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanContent(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at javax.xml.parsers.DocumentBuilder.parse(Unknown Source) at com.temenos.t24browser.xml.XMLTemplate.cleanXmlDoc(XMLTemplate.java:352) at com.temenos.t24browser.xml.XMLTemplate.createXMLDocument(XMLTemplate.java:239) at com.temenos.t24browser.xml.XMLTemplate.(XMLTemplate.java:195) at com.temenos.t24browser.xml.XMLParameters.(XMLParameters.java:40) at com.temenos.t24browser.xml.XMLRequestManager.(XMLRequestManager.java:155) at com.temenos.t24browser.utils.PropertyManager.(PropertyManager.java:51) at com.temenos.t24browser.utils.BrowserParameters.(BrowserParameters.java:51) at com.temenos.t24browser.beans.TemenosBean.readBrowserParameters(TemenosBean.java:1204) at com.temenos.t24browser.beans.TemenosBean.(TemenosBean.java:254) at com.temenos.t24browser.beans.BrowserBean.(BrowserBean.java:138) at com.temenos.t24browser.servlets.BrowserServlet.doPost(BrowserServlet.java:302) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.temenos.t24browser.security.BrowserFilter.doFilter(BrowserFilter.java:95) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.temenos.t24browser.servlets.ObfuscationServletFilter.doFilter(ObfuscationServletFilter.java:57) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.temenos.t24browser.servlets.EncodingFilter.doFilter(EncodingFilter.java:58) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) Jan 26, 2009 3:38:09 PM org.apache.catalina.core.ApplicationContext log we have tested our applicaton with 5.5.15 where we have not faced this issues . we also tried to set JAVA_OPTS=-Xmx024M in catalina.sh but still get the same error . Could you please let us know whether this can be sorted out with any settings in tomcat -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
Re: View towards refactoring changes?
We once tried to merge them, it didn't pan out as we thought. They eventually drifted apart. They are probably better left as they are for now. The connectors are fairly complex and start merging them will almost guaranteed break them. The NIO connector for example, is spaghetti code heaven, with all kinds of edge cases, that may seem easy to refactor but are not. but the code works which is more important than that it looks pretty. I'm planning on rewriting the NIO connector, but wouldn't dare to do that in the existing code base, it would take a long time to restabilize it again, instead I would create a sandbox project, and work on it there. You can see in trunk, we've already done some refactoring by extracting thread pooling code into outside classes. Filip Kirk True wrote: Hi all, There are a number of places in NioEndpoint and JIoEndpoint that share a good portion of common code. The accessors for common properties take up a good chunk, but there's also some boilerplate code for checking if we're paused, running, etc. There are a lot of places where variable and method scope could be cleaned up too. Obviously I can't commit this code myself, but if I submitted patches for it, would they be looked upon favorably or ignored as noise? :) Thanks, Kirk - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r737765 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: fhanik Date: Mon Jan 26 17:46:19 2009 New Revision: 737765 URL: http://svn.apache.org/viewvc?rev=737765&view=rev Log: votes Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=737765&r1=737764&r2=737765&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Jan 26 17:46:19 2009 @@ -35,20 +35,20 @@ still exists. http://svn.apache.org/viewvc?view=rev&revision=683969 +1: markt, funkman - 0: remm (looks risky, very minor problem) + 0: remm (looks risky, very minor problem), fhanik - minor problem -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45608 Prevent race condition for allocate/deallocate in StandardWrapper http://svn.apache.org/viewvc?rev=685177&view=rev - +1: markt, funkman + +1: markt, funkman, fhanik 0: remm: The only unsafe usage of this field is to implement the gimmick loop-wait hack, which to me means adding any sort of sync is not worth it. -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45074 http://svn.apache.org/viewvc?rev=689402&view=rev - +1: jfclere, funkman + +1: jfclere, funkman, fhanik 0: markt: The OP was using linux so I assume they saw some benefit. If this is goign to be applied, the docs should be updated as well. @@ -94,12 +94,13 @@ +1: markt +1: funkman (prefer to also remove Serializable from trunk) 0: remm (StdContext was marked as Serializable for an experiment; obviously it won't work) + 0: not sure what to serialize here, don't see it as necessary -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45933 Don't use xml parser from web-app to process tld files http://svn.apache.org/viewvc?rev=701355&view=rev - +1: markt, funkman + +1: markt, funkman, fhanik -0: remm (it is a refactoring, and is not appropriate to me in 6.0.x) markt - It is a refactoring but the refactoring was necessary to change when TLDs were processed to avoid the bug. It @@ -110,10 +111,14 @@ http://svn.apache.org/viewvc?rev=701358&view=rev +1: markt, funkman -0: remm (I also do not think the patch is a good idea as a backport) + -0: fhanik - the bug talks about WEB-INF/lib and reload, that would be when reload="true" which should be considered development only + So to make this bug actually worth while fixing, and not impact performance, then it should only do this check on files that + are relevant to the reload of an application, in other words a watched resource * Backport NCDFE fix from trunk (TCK failures without it) http://svn.apache.org/viewvc?rev=640888&view=rev +1: markt + +1: fhanik - trivial change 0: remm (no clue how it can cause a NCDF, and the TCK actually works for me; besides that code is really old to me, so where would this come from ?) -1: @@ -161,7 +166,7 @@ clashes http://svn.apache.org/viewvc?rev=731651&view=rev http://svn.apache.org/viewvc?rev=732863&view=rev - +1: markt, remm + +1: markt, remm, fhanik -1: * Provide deployment feedback - ie when deployment succeeds but startup fails, it should return FAIL @@ -172,15 +177,15 @@ * Deprecate unused code (with a view to deleting it in TC7 http://svn.apache.org/viewvc?view=rev&revision=719119 http://svn.apache.org/viewvc?view=rev&revision=719124 - +1: markt + +1: markt, fhanik -1: * Remove duplicate definitions and make normalise consistent http://svn.apache.org/viewvc?rev=734734&view=rev - +1: markt, remm + +1: markt, remm, fhanik -1: * Align installer licenses with main license file http://svn.apache.org/viewvc?rev=734743&view=rev - +1: markt + +1: markt, fhanik -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r737768 - in /tomcat/tc6.0.x/trunk: STATUS.txt java/org/apache/catalina/startup/Catalina.java java/org/apache/catalina/startup/LocalStrings.properties
Author: fhanik
Date: Mon Jan 26 17:55:19 2009
New Revision: 737768
URL: http://svn.apache.org/viewvc?rev=737768&view=rev
Log:
Print out user friendly message during shutdown without shutdown port
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/LocalStrings.properties
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=737768&r1=737767&r2=737768&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Jan 26 17:55:19 2009
@@ -150,11 +150,6 @@
+1: markt, fhanik, remm
-1:
-* Print user friendly message when attempting to shutdown and shutdown port is
disabled
- http://svn.apache.org/viewvc?rev=730178&view=rev
- +1: fhanik, remm, funkman
- -1:
-
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=36923
If EL is disabled, treat it as template text
http://svn.apache.org/viewvc?rev=730590&view=rev
Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java?rev=737768&r1=737767&r2=737768&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java Mon Jan
26 17:55:19 2009
@@ -417,15 +417,20 @@
// Stop the existing server
try {
-String hostAddress =
InetAddress.getByName("localhost").getHostAddress();
-Socket socket = new Socket(hostAddress, server.getPort());
-OutputStream stream = socket.getOutputStream();
-String shutdown = server.getShutdown();
-for (int i = 0; i < shutdown.length(); i++)
-stream.write(shutdown.charAt(i));
-stream.flush();
-stream.close();
-socket.close();
+if (server.getPort()>0) {
+ String hostAddress =
InetAddress.getByName("localhost").getHostAddress();
+ Socket socket = new Socket(hostAddress, server.getPort());
+ OutputStream stream = socket.getOutputStream();
+ String shutdown = server.getShutdown();
+ for (int i = 0; i < shutdown.length(); i++)
+ stream.write(shutdown.charAt(i));
+ stream.flush();
+ stream.close();
+ socket.close();
+} else {
+log.error(sm.getString("catalina.stopServer"));
+System.exit(1);
+}
} catch (IOException e) {
log.error("Catalina.stop: ", e);
System.exit(1);
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/LocalStrings.properties?rev=737768&r1=737767&r2=737768&view=diff
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/LocalStrings.properties
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/LocalStrings.properties
Mon Jan 26 17:55:19 2009
@@ -93,3 +93,4 @@
userConfig.error=Error deploying web application for user {0}
userConfig.start=UserConfig: Processing START
userConfig.stop=UserConfig: Processing STOP
+catalina.stopServer=No shutdown port configured in server.xml. Please shut
down server through OS signal. Server not shut down by external JVM.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r737772 - in /tomcat/tc6.0.x/trunk: STATUS.txt java/org/apache/catalina/manager/LocalStrings.properties java/org/apache/catalina/manager/ManagerServlet.java webapps/docs/changelog.xml
Author: fhanik
Date: Mon Jan 26 18:03:25 2009
New Revision: 737772
URL: http://svn.apache.org/viewvc?rev=737772&view=rev
Log:
Manager application reports FAIL if application didn't start successfully
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/LocalStrings.properties
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/ManagerServlet.java
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=737772&r1=737771&r2=737772&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Jan 26 18:03:25 2009
@@ -164,11 +164,6 @@
+1: markt, remm, fhanik
-1:
-* Provide deployment feedback - ie when deployment succeeds but startup fails,
it should return FAIL
- http://svn.apache.org/viewvc?rev=731644&view=rev
- +1: fhanik, funkman, markt, remm
- -1:
-
* Deprecate unused code (with a view to deleting it in TC7
http://svn.apache.org/viewvc?view=rev&revision=719119
http://svn.apache.org/viewvc?view=rev&revision=719124
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/LocalStrings.properties?rev=737772&r1=737771&r2=737772&view=diff
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/LocalStrings.properties
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/LocalStrings.properties
Mon Jan 26 18:03:25 2009
@@ -61,6 +61,7 @@
managerServlet.configured=OK - Deployed application from context file {0}
managerServlet.deployed=OK - Deployed application at context path {0}
managerServlet.deployFailed=FAIL - Failed to deploy application at context
path {0}
+managerServlet.deployedButNotStarted=FAIL - Deployed application at context
path {0} but context failed to start
managerServlet.exception=FAIL - Encountered exception {0}
managerServlet.deployed=OK - Deployed application at context path {0}
managerServlet.invalidPath=FAIL - Invalid context path {0} was specified
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/ManagerServlet.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/ManagerServlet.java?rev=737772&r1=737771&r2=737772&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/ManagerServlet.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/ManagerServlet.java
Mon Jan 26 18:03:25 2009
@@ -827,8 +827,10 @@
}
}
context = (Context) host.findChild(path);
-if (context != null && context.getConfigured()) {
+if (context != null && context.getConfigured() &&
context.getAvailable()) {
writer.println(sm.getString("managerServlet.deployed",
displayPath));
+} else if (context!=null && !context.getAvailable()) {
+
writer.println(sm.getString("managerServlet.deployedButNotStarted",
displayPath));
} else {
// Something failed
writer.println(sm.getString("managerServlet.deployFailed",
displayPath));
Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=737772&r1=737771&r2=737772&view=diff
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Mon Jan 26 18:03:25 2009
@@ -35,6 +35,12 @@
+
+Manager application prints FAIL if application was deployed but failed
to start (fhanik)
+
+
+When shutdown port is disabled, print user friendly message and not a
stack trace. (fhanik)
+
37458: Correct sync issue that leads to NPE in rare
circumstances. Patch provided by Konstantin Kolinko. (markt)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 44679] Cookies are treated differently between 6.0.16 and 6.0.14
https://issues.apache.org/bugzilla/show_bug.cgi?id=44679 --- Comment #31 from Peter Pichler 2009-01-26 12:06:15 PST --- 1-3) Browser Support for cookie values containing "=" I have a lot of experience with using base64 encoded binary information in cookie values. We use it since at least three years with serval 10 requests per hour from all brosers imaginabel. There is no browser or other HTTP component (Content-Switch, proxy,firewall,...)I know, which does not support the "=" character in cookie0 values. (if you know one except the newer versions of the tomcat servlet engine... please tell me) Beside... cookie0 spec allows "=" mark in cookie0 value... so it would be a problem of the browser, if this char would not be supported... An "=" character in a cookie0 value does not produce an ambiguity = >From the beginning to the first "=" mark it is the cookie name... The value starts at the first char after the "=" mark an ends when an semicolon (;) appears (or at the end of the line). I see no problems to determinate a distinct interpretation of a cookie0 Header, if there is an equal mark character in its value. Please correct me, if I forgot anything... RFC2109 === It is not ok to argue with RFC2109, when we are talking about version0 cookies... As already mentioned... RFC2109 has been obsoleted by RFC 2965... So it make no sense to argue with this RFC in any case Chapter Abstract first page of RFC2965 This document reflects implementation experience with RFC 2109 and obsoletes it. I agree... the basic problem is in the servlet spec === You are right... the basic problem is the servlet spec. They still refer the obsoleted Cookie1 RFC and ignore the actual spec RFC2965. (further inconsitancies should be corrected; like saying "use base64 encoding for binary information" in the first sentence" and "you should not use characters like ... slash, the equal mark,..." in the next sentence...) I do not want to bother you... I want to help to improve the quality of the tomcat engine... I think tomcat should support cookie0 with all its features,... (It is a horror, that a .NET and a tomcat application can not share information with a base64 encoded cookie... not because .NET is so week... but because tomcat is not able to handle cookie0 values, containing a "="). I will not reopen this bug again, cause I do not have new arguments. (I do not understand, why this bug has been closed but I do not have the time to play the reopen-close game...). Please read again my arguments and think about reopening this bug... Especially because you are trying to solve security issues, you should take care on backward compatibility... (when writing a new HTML-app its no problem, to URL-Encode cookie-values...) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
RE: View towards refactoring changes?
Tomcat seems to be becoming reasonably stable again. Please do not disturb the code base for a few more months. These are 'nice' improvements but IMO not worth the potentially new bugs! Thank you -- George > Date: Sun, 25 Jan 2009 23:44:54 -0800 > From: k...@mustardgrain.com > To: dev@tomcat.apache.org > Subject: View towards refactoring changes? > > Hi all, > > There are a number of places in NioEndpoint and JIoEndpoint that share a > good portion of common code. The accessors for common properties take up > a good chunk, but there's also some boilerplate code for checking if > we're paused, running, etc. There are a lot of places where variable and > method scope could be cleaned up too. > > Obviously I can't commit this code myself, but if I submitted patches > for it, would they be looked upon favorably or ignored as noise? :) > > Thanks, > Kirk > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org >
