Eric, Damn. I used server-noexamples.xml.config which as it turned out still uses the deprecated connector. Probably it has not been updated for quite a while. I'll re-test stuff and get back to you as soon as I know more. Cookies are still my department.
Cheers Oleg On Tue, 2003-11-04 at 22:29, Eric Johnson wrote: > Oleg, > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
