Http Keep-Alive
Does anyone know the property in the server.xml file on Tomcat for switching off http keep-alives? I'm using version 3.2.1. I can't find a listing for this deprecated version - Thanks, Jamie. ** Disclaimer: This message may contain privileged or confidential information. If you are not the intended recipient, please notify the sender and delete this message. Please be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. Views expressed in this message are those of the individual sender and are not necessarily the views of Streamdoor Ltd, unless otherwise stated. Although Streamdoor Ltd has taken precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage caused arising from the use of this email or attachment. www.streamdoor.com **
Re: Http Keep-Alive
As I recall, TC 3.2.x only has a HTTP/1.0 Connector. In particular, it never respects HTTP keep-alives. Jamie Spurr [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Does anyone know the property in the server.xml file on Tomcat for switching off http keep-alives? I'm using version 3.2.1. I can't find a listing for this deprecated version - Thanks, Jamie. ** Disclaimer: This message may contain privileged or confidential information. If you are not the intended recipient, please notify the sender and delete this message. Please be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. Views expressed in this message are those of the individual sender and are not necessarily the views of Streamdoor Ltd, unless otherwise stated. Although Streamdoor Ltd has taken precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage caused arising from the use of this email or attachment. www.streamdoor.com ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep Alive
On Wed, 02 Mar 2005 16:55:48 -0800 (BAlex Chen [EMAIL PROTECTED] wrote (B (B I am using Tomcat as my web server. I am using AXIS for SOAP. I notice (B via ethereal that the are a lot of (B port opening from the client side for the HTTP (SOAP) requests. I would (B like to keep the socket open (B for the client. How do I make the tomcat server keep the socket open? (B Is there a setting in the server configuration that can do this? (B (BIf this is a question, and not an elliptical response, please start a (Bnew thread and include more information, maybe some of your code? (B (B-- (BJoel Rees [EMAIL PROTECTED] (Bdigitcom, inc. $B3t<02q
Keep Alive
I am using Tomcat as my web server. I am using AXIS for SOAP. I notice via ethereal that the are a lot of port opening from the client side for the HTTP (SOAP) requests. I would like to keep the socket open for the client. How do I make the tomcat server keep the socket open? Is there a setting in the server configuration that can do this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cannot get keep -alive to work with SSL
I am running Tomcat standalone with SSL turned on but the TCP/IP connections keep getting closed even though I am sending a HTTP header indicating keep alive. I would greatly appreciate any help on this issue. Tim McClure - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cannot get keep -alive to work with SSL
You'll need to post more info if you want any real help. At the very least, which Tomcat version you are using. McClure, Timothy J(IndSys, GE Interlogix) [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I am running Tomcat standalone with SSL turned on but the TCP/IP connections keep getting closed even though I am sending a HTTP header indicating keep alive. I would greatly appreciate any help on this issue. Tim McClure - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: KEEP-ALIVE
Er.. Why is this attribute nowhere in the TC docs?? -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: 14 March 2003 07:51 To: [EMAIL PROTECTED] Subject: Re: KEEP-ALIVE If you are using the CoyoteConnector (the default for 4.1.x), then set the maxKeepAliveRequests=1 attribute on the Connector. This will effectively disable Keep-Alives. Carlos Manuel Belo [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] We are using TomCat without Apache and using http 1.1 I would like to disconnect keep alive to make a workaround. I cannot find a way to do this. Can you please help me? Best Regards Carlos Belo - 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]
FW: KEEP-ALIVE
We are using TomCat without Apache and using http 1.1 I would like to disconnect keep alive to make a workaround. I cannot find a way to do this. Can you please help me? Best Regards Carlos Belo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: KEEP-ALIVE
If you are using the CoyoteConnector (the default for 4.1.x), then set the maxKeepAliveRequests=1 attribute on the Connector. This will effectively disable Keep-Alives. Carlos Manuel Belo [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] We are using TomCat without Apache and using http 1.1 I would like to disconnect keep alive to make a workaround. I cannot find a way to do this. Can you please help me? Best Regards Carlos Belo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLM / Connection: Keep-Alive / HTTP 1.0
On Thu, 2 Jan 2003, Bill Barker wrote: | There is a problem with HTTP/1.0 Keep-Alive in 4.1.12. See | http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12783 for more | information. If this looks like your problem, then upgrading to 4.1.18 | should fix it. Thanks a lot. I am actually using 4.1.18, but this still helped me get further, I can now get directly in using the NTLM stuff with _Coyote_ and HTTP/1.1. But still, the HTTP/1.0 Keep-Alive is, in the thrid NTLM round as described, still not honored, and the I get a Connection: close (and indeed it is). However, another problem is that I can't get through mod_jk (1.2.2) with persistent connections (Keep-Alives), even with HTTP/1.1. Do you (or anyone) have any ideas here? -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
NTLM / Connection: Keep-Alive / HTTP 1.0
We're having a problem surrounding Tomcat when using NTLM authentication (Windows NT/2000 single sign-on through IE), when Internet Explorer decides that it should use HTTP 1.0. The problem is that NTLM _must_ go three times back-and-forth on the same connection. It is a connection-level authentication mechanism, rather than a session-oriented mechanism, probably violating a dozen RFCs. However, this requires that the server does Keep-Alive connections. The whole system works like a charm with HTTP 1.1, where Tomcat is eager to do keep-alive. But, if the browser is set up to do HTTP 1.0 only (as you can with IE, also through the policy system for windows, as a company here have done!), then Tomcat refuses to do keep-alive. A RFC out there (http:1.0 2068) states that if the client adds the string Connection: Keep-Alive, then the server should still do keep-alive, even on 1.0. This is not the fact with Tomcat (4.1.12); it always and still closes the connection if the client requests HTTP 1.0 _with_ Connection: Keep-alive (as verified using telnet). We've banged our heads against this for some time now, and would like to know if anyone have any ideas for solutions. One idea that haven't been exhausted yet is whether any of the connectors available between apache httpd and tomcat will behave differently that tomcat's native http connector? Is this an probable avenue? Any help would be greatly apreciated! PS: Check out the excellent jcifs project for more background on NTLM and CIFS, http://jcifs.samba.org/ -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: NTLM / Connection: Keep-Alive / HTTP 1.0
There is a problem with HTTP/1.0 Keep-Alive in 4.1.12. See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12783 for more information. If this looks like your problem, then upgrading to 4.1.18 should fix it. Endre Stølsvik [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... We're having a problem surrounding Tomcat when using NTLM authentication (Windows NT/2000 single sign-on through IE), when Internet Explorer decides that it should use HTTP 1.0. The problem is that NTLM _must_ go three times back-and-forth on the same connection. It is a connection-level authentication mechanism, rather than a session-oriented mechanism, probably violating a dozen RFCs. However, this requires that the server does Keep-Alive connections. The whole system works like a charm with HTTP 1.1, where Tomcat is eager to do keep-alive. But, if the browser is set up to do HTTP 1.0 only (as you can with IE, also through the policy system for windows, as a company here have done!), then Tomcat refuses to do keep-alive. A RFC out there (http:1.0 2068) states that if the client adds the string Connection: Keep-Alive, then the server should still do keep-alive, even on 1.0. This is not the fact with Tomcat (4.1.12); it always and still closes the connection if the client requests HTTP 1.0 _with_ Connection: Keep-alive (as verified using telnet). We've banged our heads against this for some time now, and would like to know if anyone have any ideas for solutions. One idea that haven't been exhausted yet is whether any of the connectors available between apache httpd and tomcat will behave differently that tomcat's native http connector? Is this an probable avenue? Any help would be greatly apreciated! PS: Check out the excellent jcifs project for more background on NTLM and CIFS, http://jcifs.samba.org/ -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
HTTP Keep Alive in Tomcat
Hi, Does Tomcat use HTTP keey alive by default? In other words, Tomcat does not close the socket connection with the client AFTER the servlet finishes the doGet() or doPut() call? If yes, is this a Tomcat specified implementation? Or it is defined in the Servlet spec? Also, is it possible to config the HTTP keey alive timer value within Tomcat? Thanks for any help. Sam __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTP Keep Alive in Tomcat
Sam Cheung [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi, Does Tomcat use HTTP keey alive by default? In other words, Tomcat does not close the socket connection with the client AFTER the servlet finishes the doGet() or doPut() call? Tomcat 3.3.1 does not (unless you plug in the CoyoteConnector). All 4.x versions do. If yes, is this a Tomcat specified implementation? Or it is defined in the Servlet spec? Also, is it possible to config the HTTP keey alive timer value within Tomcat? It is possible to config. I believe that the attribute is connectionTimeout for 4.0.x, and soTimeout for 4.1.x. 4.1.x also has a maxKeepAliveRequests attribute that can be used to effectively disable keep-alive (by setting it to 1). Thanks for any help. Sam __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Keep-Alive. Was: IE 5 on Mac is incompatible with TC 4?
Rob, I'm not sure I understand what you want, but regarding session cookies, IE5/Mac and SSL, I think that the problem is that TC 4 does not seem to automatically support persistant TCP-connections which both gives bad performance, and confuses at least one browser to the extent that it stops sending cookie data. Anders - Original Message - From: Rob Cartier [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Sunday, March 10, 2002 13:14 Subject: RE: IE 5 on Mac is incompatible with TC 4? How would you do that if you are using Form authentication and the web.xml file directs them to a loginpage before they access the index.jsp Have the same problem and found that If they accept session cookies then all is ok Your help would be greatly appreciated. -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Friday, March 08, 2002 7:04 AM To: Tomcat Users List Subject: SSL: IE 5 on Mac is incompatible with TC 4? Now i have digged a little bit further in this. The IE 5 Mac missing session cookie problem only occurs when using SSL. Too bad our app needs SSL. Anders - Original Message - From: Anders Rundgren [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Friday, March 08, 2002 11:27 Subject: IE 5 on Mac is incompatible with TC 4? Hi, I have a Tomcat app using sessions based on cookies (i.e. std way) that works with a huge set of browsers and OSes. But on Mac using IE 5 it does not. The culprit seems to be that session cookies are not compatible in some way as they are not visible in TC. Is this a known problem? BTW, the configuration is Apache on Linux, using ajp1.3 and TC 4.0.2 cheers, Anders R -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Keep-Alive. Was: IE 5 on Mac is incompatible with TC 4?
I am trying to use encodeURL for all my href's and login page but I get: Apache Tomcat/4.0.2 - HTTP Status 400 - Invalid direct reference to form login page type Status report message Invalid direct reference to form login page description The request sent by the client was syntactically incorrect (Invalid direct reference to form login page). If session cookies are off. Any ideas how to fix this mess ? loginpage.jsp html body table border=0 cell= padding=0 size=480 width=640 tbody tr td nowrap= width=150p align=Centerimg src=../marslogo.gif height=150 width=150/p/td td nowrap= width=420h2 align=Leftfont face=Trebuchet MSSouthern New England Army Mars/fontbr font face=Trebuchet MSSecure Site/font/h2 /td /tr /tbody /table % System.out.println(JSP== + request.getRemoteUser() + | + request.getRequestURI() + | + request.getRemoteAddr() + | + new java.util.Date().toString() + | + request.getHeader(User-Agent) ); % % String url = j_security_check;jsessionid= + session.getId(); % h2Login page /h2 form method=POST action='%= response.encodeURL(url) %' table border=0 cell padding=0 width=480 tr td nowrapfont face=FixedsysUsername:/font/td td input type=text name=j_username/td /tr tr td nowrapfont face=FixedsysPassword:/font/td td input type=password name=j_password/td tr tr td /td tdinput type=submit value=Login/td /tr br /table /form /body /html -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 10, 2002 11:22 AM To: Tomcat Users List Subject: Keep-Alive. Was: IE 5 on Mac is incompatible with TC 4? Rob, I'm not sure I understand what you want, but regarding session cookies, IE5/Mac and SSL, I think that the problem is that TC 4 does not seem to automatically support persistant TCP-connections which both gives bad performance, and confuses at least one browser to the extent that it stops sending cookie data. Anders - Original Message - From: Rob Cartier [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Sunday, March 10, 2002 13:14 Subject: RE: IE 5 on Mac is incompatible with TC 4? How would you do that if you are using Form authentication and the web.xml file directs them to a loginpage before they access the index.jsp Have the same problem and found that If they accept session cookies then all is ok Your help would be greatly appreciated. -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Friday, March 08, 2002 7:04 AM To: Tomcat Users List Subject: SSL: IE 5 on Mac is incompatible with TC 4? Now i have digged a little bit further in this. The IE 5 Mac missing session cookie problem only occurs when using SSL. Too bad our app needs SSL. Anders - Original Message - From: Anders Rundgren [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Friday, March 08, 2002 11:27 Subject: IE 5 on Mac is incompatible with TC 4? Hi, I have a Tomcat app using sessions based on cookies (i.e. std way) that works with a huge set of browsers and OSes. But on Mac using IE 5 it does not. The culprit seems to be that session cookies are not compatible in some way as they are not visible in TC. Is this a known problem? BTW, the configuration is Apache on Linux, using ajp1.3 and TC 4.0.2 cheers, Anders R -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Keep-Alive dead? Was: IE 5 on Mac is incompatible with TC 4?
Dave, Perhaps there is something in the configuration of your server (server.xml), or its default webapp settings (conf/web.xml), or the configuration of your webapp (WEB-INF/web.xml) that is causing the session cookie to be set as a secure cookie. There is one thing that differs between the TC and IIS-headers I supplied: TC does Connection: Close while IIS does Connection: Keep-Alive. This could very well be the reason why ;Secure is added (which *may* be the culprit although IE 5/Mac ought to be capable of handling this) as a closed-down connection loses its security context which requires this explicit marking of the cookies' secure origin. I guess... If you're only responding to HTTPS, then you probably don't need to set the Secure flag on the cookie anyway. I would bet that if you can find a way to get tomcat not to set that flag, your problem may go away. I have not found anything in this area that can be configured. A google search revealed that TC requires HTTP 1.1 to support Keep-Alive but when I do Netstat using NN 6.2 and IE 5 on W2K, I see no sign of any keep-alives, just huge amounts of dead or dying TCP connections! Anders -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Tomcat and Keep-Alive
Does Tomcat support keep-alive socket connections? Tim -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: windows 2K + IIS 5.0 + cgi program + HTTP connection Keep Alive doesn't work
Hi, Scott Sorry to bother you again. I've runned more tests, and found that for *.html files connection is kept alive, while for cgi program, it always close connection. Even when I just change my cgi program name with .html extension, connection becomes alive though the displayed content is in a mess. I've tried a simple html file and a cgi program which just produce the same html file. The *.html file works fine(I mean connection keeps alive) while not the cgi program. Also I found that in the HTTP GET header by Inetnet Explorer there is one: If-None-Match: some random value here, and in the reply by IIS there is a ETag: same value as in If-None-Match. Are such headers defined in HTTP 1.0 or 1.1? Related to connection problem? Thanks in advance! Xuemei - Original Message - From: Scott Stahlman [EMAIL PROTECTED] To: xuemei [EMAIL PROTECTED] Sent: Saturday, May 19, 2001 1:01 PM Subject: RE: windows 2K + IIS 5.0 + cgi program + HTTP connection Keep Alive doesn't work Sorry for the late reply. Can you post this question on the newsgroup? It would be a great help, as you can probably imagine I must account for how I spend my time and posting this to the newsgroup allows us to do that. But see if http://support.microsoft.com/support/kb/articles/Q195/1/79.asp helps you at all. Thanks, Scott -Original Message- From: xuemei [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 16, 2001 4:20 AM To: Scott Stahlman Subject: windows 2K + IIS 5.0 + cgi program + HTTP connection Keep Alive doesn't work Hi, Scott I found your email address from the IIS Newsgroup. Sorry to bother you, but I really need some help soon. I just begin to use windows 2k Server and IIS 5.0 for my cgi program. The problem is that the HTTP connection Keep Alive is ON(by default), and the POST request to my cgi program also ask for Connection: Keep-Alive, but IIS always close the connection after sending reply to each request. There's no error at all, and even data is sent back though it's expired to Sender. How can I make HTTP 1.1 persistent connection work with IIS 5.0 on Windows 2000 Server? In fact, I have same problem with IIS 4.0 on NT 4.0 Server. Thank you very very much for your kind help! Xuemei
