I'm glad you sent along the file! It's funny - other than that one file, I'd say you exactly duplicated the environment I'm using. That one file is key, though.
It would appear that your version of server.xml trumps the default "connector" choice. The default server.xml reads:
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="8080" minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"
acceptCount="100" debug="0" connectionTimeout="20000"
useURIValidationHack="false" disableUploadTimeout="true" />and yours reads:
<Connector className="org.apache.catalina.connector.http.HttpConnector"
port="8080" minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"
acceptCount="10" debug="0" connectionTimeout="60000"/>As far as the docs on the Tomcat site go, this:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/connectors.html
indicates that the "HttpConnector" is "deprecated", and the "CoyoteConnector" is the one to use.
I replaced the "Connector" entry in your server.xml (which worked for me, and generated no test failures, by the way), with the one from the Tomcat original, and reproduced the problem.
By the way, when I last looked at the older connector, you most definitely didn't want to use it with Tomcat 4.1.18. It turns out that any GET request that didn't include a "Content-Length" line would be closed by the connector, rather than assuming that the GET request had no content and reuse the connection persistently. I got really horrible behavior where each request from my web browser meant a new connection to the server. So much for HTTP 1.1. The newer CoyoteConnector doesn't show this behavior.
Of course, this brings us full circle to the original problem - which one is right?
-Eric.
Oleg Kalnichevski wrote:
Eric, I just installed Tomcat 4.1.29 on my home PC running Redhat 9 and Sun JDK 1.4.2. I can't reproduce the problem. All tests pass. The only thing I did differently was tweaking tomcat's server.xml (attached below) to disable stuff that I do not need. I's unlikely that it should have any bearing on the problem, but who knows.
Oleg
On Tue, 2003-11-04 at 20:53, Eric Johnson wrote:
Oleg,
I hate bugs like this! I suppose if it is working for you, there's hope it can work for me.
I'm working against a completely stock 4.1.29 install on Linux, using Sun's JDK 1.4.2. When I say "stock" 4.1.29 build, I expanded the file after download, dropped httpclienttest folder into webapps, then started up Tomcat with a "./catalina.sh run". Then I ran the tests as reported.
-Eric.
Kalnichevski, Oleg wrote:
Eric,
Strangely enough, I installed Tomcat 4.1.29 yesterday and had no failing test cases of whatsoever. I reran the test cases with the latest code from CVS HEAD and 2.0 branch against Tomcat 4.1.29 after having read your message. Again, no failing test cases.
Did you keep your old server.xml file?
Oleg
-----Original Message----- From: Eric Johnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 04, 2003 17:11 To: HttpClient Subject: Cookie test case failures with Tomcat 4.1.29
It would seem that the latest Tomcat (4.1.29) has engaged in a subtle change in behavior with respect to cookies. When I ran it this morning, nine of the cookie related test cases failed. Last week, I was running with Tomcat 4.1.27, and everything worked fine.
Since I had it readily available, I fell back to Tomcat 4.1.18 (I deleted 4.1.27, unfortunately, and Apache is no longer hosting it) and ran the tests again, and got all of the tests to pass with no errors.
Upon inspection, the failures would seem to be due to the test servlet returning:
<tt>simplecookie=value</tt>
instead of:
<tt>simplecookie="value"</tt>
Which is right - our test cases, or the new behavior?
-Eric.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
