Re: tomcat-users.xml Unix file permissions and security (possible patch)
Hi, On 12.02.2009 18:06, Petr Sumbera wrote: Hi all, From Tomcat tar archive I get: ls -l apache-tomcat-6.0.18/conf/tomcat-users.xml -rw--- 1 tomcat staff 1107 Jul 21 2008 apache-tomcat-6.0.18/conf/tomcat-users.xml But Tomcat itself changes this during its first run: ls -l apache-tomcat-6.0.18/conf/tomcat-users.xml -rw-r--r- 1 tomcat staff 70 Feb 12 08:31 apache-tomcat-6.0.18/conf/tomcat-users.xml This is bad from security perspective. Why not directly write to the file and avoid renaming. This risk of problem during saving is probably smaller then readable passwords... See attached patch (it would need some more clearance). You can set the attribute readonly to "true" in the configuration of the user database. Then Tomcat will not write to the file and instead simply read and use it. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46503] Garbage characters in cluster domain field
https://issues.apache.org/bugzilla/show_bug.cgi?id=46503 Martin Helff changed: What|Removed |Added CC||mar...@helff.net -- 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: tomcat-users.xml Unix file permissions and security (possible patch)
On 13/02/2009, Rainer Jung wrote: > Hi, > > On 12.02.2009 18:06, Petr Sumbera wrote: > > > Hi all, > > > > From Tomcat tar archive I get: > > > > ls -l apache-tomcat-6.0.18/conf/tomcat-users.xml > > -rw--- 1 tomcat staff 1107 Jul 21 2008 > > apache-tomcat-6.0.18/conf/tomcat-users.xml > > > > But Tomcat itself changes this during its first run: > > > > ls -l apache-tomcat-6.0.18/conf/tomcat-users.xml > > -rw-r--r- 1 tomcat staff 70 Feb 12 08:31 > > apache-tomcat-6.0.18/conf/tomcat-users.xml > > > > This is bad from security perspective. Why not directly write to the file > > and avoid renaming. This risk of problem during saving is probably smaller > > then readable passwords... > > > > See attached patch (it would need some more clearance). > > > > You can set the attribute readonly to "true" in the configuration of the > user database. Then Tomcat will not write to the file and instead simply > read and use it. I agree with the OP - IMO it is still bad that Tomcat changes the file permissions. > Regards, > > Rainer > > > - > 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
tomcat-native: multicast on win32
hi once again i have been trying to figure out why my tomcat native based mina acceptor won't join a speicified multicast group. the call goes through Multicast.join() over the tomcat native code to apr_mcast_join which in turn calls do_mcast in the apr multicast.c file. then it goes to os specific code, and in the end i get APR_SUCCESS back. but wether when specifying an iface of 0 (use default) nor when giving a specific interface does anything actually happen. no igmp message is sent and no multicast group is joined. has anyone ever had similar problems, or has anyone used the apr multicast code successfully on win32 machines? lorenz - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46655] keystore's password handler
https://issues.apache.org/bugzilla/show_bug.cgi?id=46655 --- Comment #3 from Alessandro 2009-02-13 06:45:21 PST --- Connector.java contain patch code to handle new attributes (In reply to comment #2) > As far as I can tell, the jar only contains the class file for the password > handler. -- 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 46655] keystore's password handler
https://issues.apache.org/bugzilla/show_bug.cgi?id=46655 --- Comment #4 from Sebb 2009-02-13 07:07:34 PST --- (In reply to comment #3) > Connector.java contain patch code to handle new attributes (In reply to > comment > #2) Agreed, but in order to use the new attributes, the following class file (or an equivalent) needs to be provided: it.urmet.test.EnterPassword > > As far as I can tell, the jar only contains the class file for the password > > handler. > However, the jar file only contains the compiled version of that class. It would be helpful for the API of the external class to be documented. Also, please provide the Connector.java file as a patch (unified diff format) against the current code, rather than as a complete source file. Patch files are generally easier for the Tomcat committers to review. -- 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: tomcat-native: multicast on win32
Lorenz Breu wrote: hi once again i have been trying to figure out why my tomcat native based mina acceptor won't join a speicified multicast group. the call goes through Multicast.join() over the tomcat native code to apr_mcast_join which in turn calls do_mcast in the apr multicast.c file. then it goes to os specific code, and in the end i get APR_SUCCESS back. but wether when specifying an iface of 0 (use default) nor when giving a specific interface does anything actually happen. no igmp message is sent and no multicast group is joined. has anyone ever had similar problems, or has anyone used the apr multicast code successfully on win32 machines? Try Multicast.loopback if Multicast.join fails. Win32 is pretty weired, and not sure why the join doesn't work. I suppose the multicast group needs to exists before joining. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomcat-native: multicast on win32
Lorenz Breu wrote: hi once again i have been trying to figure out why my tomcat native based mina acceptor won't join a speicified multicast group. the call goes through Multicast.join() over the tomcat native code to apr_mcast_join which in turn calls do_mcast in the apr multicast.c file. then it goes to os specific code, and in the end i get APR_SUCCESS back. but wether when specifying an iface of 0 (use default) nor when giving a specific interface does anything actually happen. no igmp message is sent and no multicast group is joined. has anyone ever had similar problems, or has anyone used the apr multicast code successfully on win32 machines? Also, can you try if (Multicat.join(sock, addr, iface, source) != APR_ERROR_SUCCESS) Multicat.join(sock, addr, iface, 0); If source internal will call MCAST_JOIN_SOURCE_GROUP or IP_ADD_MEMBERSHIP if 0. IP_ADD_MEMBERSHIP can be called only once on the same network interface (accorning to the MSDN), so that might fix the issue. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomcat-native: multicast on win32
>
> Try Multicast.loopback if Multicast.join fails.
> Win32 is pretty weired, and not sure why the join doesn't work.
> I suppose the multicast group needs to exists before joining.
>
no cigar. i first expected an APR_ENOTIMPL or even a failure, but i get
APR_SUCCESS all the way... but nothing actually happens... works fine
with linux though, so i guess it's either me being lucky that linux is
catching my mistake, or there being a problem with the apr code on my
win32 machine (xp pro).
do i need to specify a source when i join a group? isn't NOT specifying
one safer than specifying one, as i want to accept all muslticast
messages to that address, no matter where they come from??
here is what i have been doing:
i actually used 0 instead of the specific interface, then i thought
windows may need to be specified an address, but both approaches do the
same thing: return success and do nothing. all individual steps below
return APR_SUCCESS.
long ifa = Address.info("192.168.2.100", Socket.APR_INET, 0, 0, pool);
Multicast.ointerface(handle, ifa);
long ra;
ra = Address.info("234.255.255.253", 0, 0, 0, pool);
Multicast.loopback(handle, true);
Multicast.join(handle, ra, ifa, 0);
Socket.optSet(handle, Socket.APR_SO_NONBLOCK, 1);
Socket.timeoutSet(handle, 0);
Socket.optSet(handle, Socket.APR_SO_REUSEADDR, 1);
Socket.optSet(handle, Socket.APR_SO_RCVBUF,
getSessionConfig().getReceiveBufferSize());
long sa;
sa = Address.info(la.getAddress().getHostAddress(), Socket.APR_INET,
la.getPort(), 0, pool);
result = Socket.bind(handle, sa);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r744160 - /tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java
Author: markt
Date: Fri Feb 13 16:17:54 2009
New Revision: 744160
URL: http://svn.apache.org/viewvc?rev=744160&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=4
keepAliveTimeout should always be used regardless of setting of
disableUploadTimeout
Modified:
tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java
Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java?rev=744160&r1=744159&r2=744160&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java Fri Feb 13
16:17:54 2009
@@ -781,7 +781,7 @@
// Parsing the request header
try {
-if (!disableUploadTimeout && keptAlive) {
+if (keptAlive) {
if (keepAliveTimeout > 0) {
socket.setSoTimeout(keepAliveTimeout);
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r744161 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Fri Feb 13 16:19:23 2009 New Revision: 744161 URL: http://svn.apache.org/viewvc?rev=744161&view=rev Log: Propose fix for 4 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=744161&r1=744160&r2=744161&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Feb 13 16:19:23 2009 @@ -163,3 +163,9 @@ http://svn.apache.org/viewvc?rev=742962&view=rev +1: remm, jfclere -1: + +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=4 + keepAliveTimeout should be used regardless of setting of disableUploadTimeout + http://svn.apache.org/viewvc?rev=744160&view=rev + +1: markt + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46666] Why is disableUploadTimeout and KeepAliveTimeout correlated in Http11 Connector?
https://issues.apache.org/bugzilla/show_bug.cgi?id=4 --- Comment #1 from Mark Thomas 2009-02-13 08:19:46 PST --- Looks reasonable to me. I have made the change in trunk and proposed it for 6.0.x. There is always a chance, particularly with the connector code, that I have missed a use case that explains why this is so. If that is the case, I am sure one of my fellow committers will point it out. -- 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
svn commit: r744165 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Fri Feb 13 16:27:14 2009 New Revision: 744165 URL: http://svn.apache.org/viewvc?rev=744165&view=rev Log: Vote 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=744165&r1=744164&r2=744165&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Feb 13 16:27:14 2009 @@ -161,7 +161,7 @@ * Fix HTTP/1.0 handling in the new AJP connectors http://svn.apache.org/viewvc?rev=742962&view=rev - +1: remm, jfclere + +1: remm, jfclere, markt -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=4 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r744166 - /tomcat/current/tc5.5.x/STATUS.txt
Author: markt Date: Fri Feb 13 16:31:45 2009 New Revision: 744166 URL: http://svn.apache.org/viewvc?rev=744166&view=rev Log: Votes Modified: tomcat/current/tc5.5.x/STATUS.txt Modified: tomcat/current/tc5.5.x/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/current/tc5.5.x/STATUS.txt?rev=744166&r1=744165&r2=744166&view=diff == --- tomcat/current/tc5.5.x/STATUS.txt (original) +++ tomcat/current/tc5.5.x/STATUS.txt Fri Feb 13 16:31:45 2009 @@ -30,10 +30,6 @@ +1: markt, rjung (when enhanced by the below added backport proposal) 0: fhanik - silently swallow an error, and default to the default config file, yoavs: don't like silent swallowing -1: - markt - You can't log it, the logging system isn't initalised at this - point. You could use System.out but that is far worse than the - current proposal given that this will occur once per context with - a default configuration and this is not an error condition. * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45576 Add support for DIGEST to the JAASRealm @@ -82,7 +78,7 @@ * Backport: Handle session suffix rewrite at JvmRouteBinderValve with parallel requests from same client http://svn.apache.org/viewvc?rev=693378&view=rev - +1: pero + +1: pero, markt -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=44382 @@ -97,13 +93,14 @@ * Correct wrong "No role found" debug message, logged in RealmBase even if a role was found. http://svn.apache.org/viewvc?rev=697158&view=rev - +1: rjung + +1: rjung, markt -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45026 Never use empty reason phrase. http://svn.apache.org/viewvc?rev=697183&view=rev +1: rjung + +1: markt (also required for other AJP connectors) -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45880 @@ -221,7 +218,7 @@ -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=39396 - Don't include TRACEE in OPTIONS response unless we know it hasn't been + Don't include TRACE in OPTIONS response unless we know it hasn't been disabled in the connector http://svn.apache.org/viewvc?rev=742714&view=rev +1: markt - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Support for httpOnly cookies in Tomcat 6.0.x
Folks, The implementation of httpOnly support in Tomcat 7 fits well with the previous httpOnly patch [1] that is currently the proposed backport for 6.0.x When originally proposed there was some concern that the v3 servlet spec may require some changes. This hasn't been the case. With that in mind could folks please review their comments and votes for this patch. I'd like to get it into 6.0.19 if posible. If you still think there is room for improvement, I'm happy to take another look at this. Some pointers as to how you think things could/should be improved would be appreciated. If you do vote for this patch, please remember to indicate your preference for using or not using httpOnly for session cookies by default. Cheers, Mark [1] http://svn.apache.org/viewvc?view=rev&revision=694992 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r744171 - in /tomcat/trunk/modules/jdbc-pool: ./ java/org/apache/tomcat/jdbc/pool/ java/org/apache/tomcat/jdbc/pool/jmx/ test/org/apache/tomcat/jdbc/test/
Author: fhanik
Date: Fri Feb 13 16:44:35 2009
New Revision: 744171
URL: http://svn.apache.org/viewvc?rev=744171&view=rev
Log:
Documentation
Modified:
tomcat/trunk/modules/jdbc-pool/.classpath
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/JdbcInterceptor.java
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/PooledConnection.java
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/jmx/ConnectionPool.java
tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/StarvationTest.java
Modified: tomcat/trunk/modules/jdbc-pool/.classpath
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/.classpath?rev=744171&r1=744170&r2=744171&view=diff
==
--- tomcat/trunk/modules/jdbc-pool/.classpath (original)
+++ tomcat/trunk/modules/jdbc-pool/.classpath Fri Feb 13 16:44:35 2009
@@ -4,7 +4,7 @@
-
+
Modified:
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/JdbcInterceptor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/JdbcInterceptor.java?rev=744171&r1=744170&r2=744171&view=diff
==
---
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/JdbcInterceptor.java
(original)
+++
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/JdbcInterceptor.java
Fri Feb 13 16:44:35 2009
@@ -23,24 +23,51 @@
import org.apache.tomcat.jdbc.pool.PoolProperties.InterceptorProperty;
/**
+ * Abstract class that is to be extended for implementations of interceptors.
+ *
* @author Filip Hanik
* @version 1.0
*/
public abstract class JdbcInterceptor implements InvocationHandler {
+/**
+ * java.sql.Connection.close()
+ */
public static final String CLOSE_VAL = "close";
+/**
+ * java.sql.Connection.toString()
+ */
public static final String TOSTRING_VAL = "toString";
-public static final String ISCLOSED_VAL = "isClosed";
+/**
+ * java.sql.Connection.isClosed()
+ */
+public static final String ISCLOSED_VAL = "isClosed";
+/**
+ * javax.sql.DataSource.getConnection()
+ */
public static final String GETCONNECTION_VAL = "getConnection";
+/**
+ * Properties for this interceptor
+ */
protected Map properties = null;
+/**
+ * The next interceptor in the chain
+ */
private JdbcInterceptor next = null;
+/**
+ * Property that decides how we do string comparison, default is reference
(==)
+ */
private boolean useEquals = false;
+/**
+ * Public constructor for instantation through reflection
+ */
public JdbcInterceptor() {
}
/**
+ * Gets invoked each time an operation on java.sql.Connection is invoked.
* {...@inheritdoc}
*/
public Object invoke(Object proxy, Method method, Object[] args) throws
Throwable {
@@ -48,14 +75,28 @@
else throw new NullPointerException();
}
+/**
+ * Returns the next interceptor in the chain
+ * @return
+ */
public JdbcInterceptor getNext() {
return next;
}
+/**
+ * configures the next interceptor in the chain
+ * @param next
+ */
public void setNext(JdbcInterceptor next) {
this.next = next;
}
+/**
+ * Performs a string comparison, using references unless the useEquals
property is set to true.
+ * @param name1
+ * @param name2
+ * @return
+ */
public boolean compare(String name1, String name2) {
if (isUseEquals()) {
return name1.equals(name2);
@@ -64,21 +105,40 @@
}
}
+/**
+ * Compares a method name (String) to a method (Method)
+ * {...@link compare(String,String)}
+ * Uses reference comparison unless the useEquals property is set to true
+ * @param methodName
+ * @param method
+ * @return true if the name matches
+ */
public boolean compare(String methodName, Method method) {
return compare(methodName, method.getName());
}
/**
* Gets called each time the connection is borrowed from the pool
+ * This means that if an interceptor holds a reference to the connection
+ * the interceptor can be reused for another connection.
* @param parent - the connection pool owning the connection
* @param con - the pooled connection
*/
public abstract void reset(ConnectionPool parent, PooledConnection con);
+/**
+ *
+ * @return the configured properties for this interceptor
+ */
public Map getProperties() {
return properties;
}
+/**
+ * Called during the creation of an interceptor
+ * The properties can be set during the configuration of an i
svn commit: r744238 - /tomcat/trunk/java/org/apache/tomcat/util/http/ServerCookie.java
Author: markt
Date: Fri Feb 13 20:46:22 2009
New Revision: 744238
URL: http://svn.apache.org/viewvc?rev=744238&view=rev
Log:
Change to ThreadLocal to prevent potential sync bottleneck on cookie creation
Modified:
tomcat/trunk/java/org/apache/tomcat/util/http/ServerCookie.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/http/ServerCookie.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/http/ServerCookie.java?rev=744238&r1=744237&r2=744238&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/http/ServerCookie.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/http/ServerCookie.java Fri Feb 13
20:46:22 2009
@@ -57,14 +57,20 @@
// Other fields
private static final String OLD_COOKIE_PATTERN =
"EEE, dd-MMM- HH:mm:ss z";
-private static final DateFormat OLD_COOKIE_FORMAT;
+private static final ThreadLocal OLD_COOKIE_FORMAT =
+new ThreadLocal() {
+protected DateFormat initialValue() {
+DateFormat df =
+new SimpleDateFormat(OLD_COOKIE_PATTERN, Locale.US);
+df.setTimeZone(TimeZone.getTimeZone("GMT"));
+return df;
+}
+};
private static final String ancientDate;
static {
-OLD_COOKIE_FORMAT = new SimpleDateFormat(OLD_COOKIE_PATTERN,
Locale.US);
-OLD_COOKIE_FORMAT.setTimeZone(TimeZone.getTimeZone("GMT"));
-ancientDate = OLD_COOKIE_FORMAT.format(new Date(1));
+ancientDate = OLD_COOKIE_FORMAT.get().format(new Date(1));
}
/**
@@ -300,12 +306,10 @@
if (maxAge == 0)
buf.append( ancientDate );
else
-synchronized (OLD_COOKIE_FORMAT) {
-OLD_COOKIE_FORMAT.format(
-new Date(System.currentTimeMillis() +
-maxAge*1000L),
-buf, new FieldPosition(0));
-}
+OLD_COOKIE_FORMAT.get().format(
+new Date(System.currentTimeMillis() +
+maxAge*1000L),
+buf, new FieldPosition(0));
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46666] Why is disableUploadTimeout and KeepAliveTimeout correlated in Http11 Connector?
https://issues.apache.org/bugzilla/show_bug.cgi?id=4 --- Comment #2 from Doug Drechsel 2009-02-13 14:42:03 PST --- Hi Mark, Thanks. I agree with your assessment of unintended consequences. The location in such well exercised code does make one pause. I am a newbie to this process. Do you have information as to how I can look at the modification in the trunk? Regards Doug -- 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
