hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Johnson <e...@tibco.com>
Subject Re: Cookie test case failures with Tomcat 4.1.29
Date Tue, 04 Nov 2003 21:29:12 GMT

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:
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?


Oleg Kalnichevski wrote:

>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.
>On Tue, 2003-11-04 at 20:53, Eric Johnson wrote:
>>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.
>>Kalnichevski, Oleg wrote:
>>>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?
>>>-----Original Message-----
>>>From: Eric Johnson [mailto:eric@tibco.com]
>>>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 
>>>instead of:
>>>Which is right - our test cases, or the new behavior?

To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org

View raw message