Re: Tomcat 4.0.3 SSL - no yellow lock in IE6
Gary, This is not a TC issue. It is how IE treat local names. Goto to Security and change settings so that all names are treated as Internet and no Intranets Anders - Original Message - From: Gary McGowan [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, April 09, 2002 09:47 Subject: Tomcat 4.0.3 SSL - no yellow lock in IE6 Hi Guys I have TC 4.0.3 with its SSL enabled on port 443, but I cannot get the little yellow lock to display on IE6. For example - if i look at https://mydomain.com the lock doesn't appear, but if I double click where the lock should be I get the certificate information. BUT if I am browsing a directory on the server (I have directory browsing enabled) - the lock appears! Anyone have any ideas?? - All would be greatly appreciated. In my server.xml file I have: Connector className=org.apache.catalina.connector.http.HttpConnector port=443 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=10 debug=0 scheme=https secure=true Factory className=org.apache.catalina.net.SSLServerSocketFactory clientAuth=false protocol=TLS/ /Connector Thanks folks! -- 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: sessions, security, and the RFCs
Ralph, I could not find anything that disallow switching between https and http in any order while maintaining. Although not a particularly good idea, it is anyhow used out there to protect passwords but be less protective about the session. I think that security issues should be dealt with as options to not outlaw schemes that actually are used. cheers, Anders - Original Message - From: Ralph Einfeldt [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Wednesday, April 03, 2002 09:28 Subject: AW: AW: AW: sessions, security, and the RFCs I can't find in the spec that the session shall be maintained if you switch from http to https. Can you provide a reference? Wouldn't this be as dangerous as to keep the session after you go back from SSL to non-SSL ? As I see it, this would open the door to anyone who could listen to the http network traffic to steel the secure session. | SRV.7.1.2 SSL Sessions | Secure Sockets Layer, the encryption technology | used in the HTTPS protocol, has a mechanism built | into it allowing multiple requests from a client | to be unambiguously identified as being part of a | session. A servlet container can easily use this | data to define a session. | 12.8 ... | The container must at least use SSL to respond to | requests to resources marked integral or confidential. | If the original request was over HTTP, the container | must redirect the client to the HTTPS port. -Ursprüngliche Nachricht- Von: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 2. April 2002 18:47 An: Tomcat Users List Betreff: Re: AW: AW: sessions, security, and the RFCs snip/ Servlet 2.3 (basis for Tomcat 4.x) added some specific requirements (such as the ability to redirect from the non-SSL port to the SSL port and maintain the session). snip/ Note -- anyone who goes from the SSL port back to the non-SSL port has just created a security hole. -- 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: AW: sessions, security, and the RFCs
Carsten, As a consequence, switching from https to http and back is about equally secure as not using SSL at all. So you are shooting yourself in the foot by thinking that everything is safe, but your webapp is just one very big hole. I would say that you are partially right. It may be valid to protect passwords in a https session and run the rest of the app (for performance reasons) in http. This is BTW how Microsoft's Passport is used in Hotmail used by 100 millions of users so this (bad habit) is definitely not that unusual. Anyway, I don't think that Tomcat should elminate this possibility. Add warnings to the "deconfiguration switch" and call it: SuboptimalSecurity="true"|"false":-) Anders -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Session lost when switching from https to http in Tomcat 4
You are right Manuel, Tomcat 4.0.2 using SSL unfortunately always sets a Secure flag on JSESSIONIDs, which do not (depending on browser) allow you to do this https-http switch. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6983 A Macintosh using IE 5 cannot even obtain a _standard_ SSL jsession due to this. This is why I have requested this behavior to become an option. The option would actually disable a cookie-RFC compliant feature, but so what, if you cannot get things to work? cheers, Anders - Original Message - From: Manuel Mall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 11:17 Subject: Session lost when switching from https to http in Tomcat 4 Has the session semantic changed between Tomcat 3 and Tomcat 4? We have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. This works fine under Apache 1.3.22 with Tomcat 3.2.1 connecting using ajp12. After upgrading to Tomcat 4.0.3 now using ajp13 the session appears not to be preserved between https and http, ie. after switching back to http the request.getSession(false) call returns null. This seems to indicate that the session tracking mechanism has changed between Tomcat 3 and Tomcat 4. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 4 I might have missed? Thanks Manuel -- 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: Session lost when switching from https to http in Tomcat 4
Gurmeet, The only known workarounds I know of are handling sessions in URLs or patching the CookieTools class which we did. Anders - Original Message - From: Gurmeet [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 13:51 Subject: RE: Session lost when switching from https to http in Tomcat 4 Hi, I just read this and tested for my app also wherein I would have the same problem in coming days. Any better way of overcoming this problem other than persisting the session manually. Regards, Gurmeet -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 4:08 PM To: [EMAIL PROTECTED]; Tomcat Users List Cc: Peter Tornberg Subject: Re: Session lost when switching from https to http in Tomcat 4 You are right Manuel, Tomcat 4.0.2 using SSL unfortunately always sets a Secure flag on JSESSIONIDs, which do not (depending on browser) allow you to do this https-http switch. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6983 A Macintosh using IE 5 cannot even obtain a _standard_ SSL jsession due to this. This is why I have requested this behavior to become an option. The option would actually disable a cookie-RFC compliant feature, but so what, if you cannot get things to work? cheers, Anders - Original Message - From: Manuel Mall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 11:17 Subject: Session lost when switching from https to http in Tomcat 4 Has the session semantic changed between Tomcat 3 and Tomcat 4? We have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. This works fine under Apache 1.3.22 with Tomcat 3.2.1 connecting using ajp12. After upgrading to Tomcat 4.0.3 now using ajp13 the session appears not to be preserved between https and http, ie. after switching back to http the request.getSession(false) call returns null. This seems to indicate that the session tracking mechanism has changed between Tomcat 3 and Tomcat 4. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 4 I might have missed? Thanks Manuel -- 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: Session lost when switching from https to http in Tomcat 4
Gurmeet, I (or rathe my college), removed the line that appends Secure to JSESSIONIDs. Anders - Original Message - From: Gurmeet [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 14:32 Subject: RE: Session lost when switching from https to http in Tomcat 4 Thanks Anders, But as you must be knowing if I implement a HttpSessionBindingListener then it would still be a problem. Can u please elaborate on the patching u did on CookieTool class. Regards Gurmeet -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 6:49 PM To: Tomcat Users List Subject: Re: Session lost when switching from https to http in Tomcat 4 Gurmeet, The only known workarounds I know of are handling sessions in URLs or patching the CookieTools class which we did. Anders - Original Message - From: Gurmeet [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 13:51 Subject: RE: Session lost when switching from https to http in Tomcat 4 Hi, I just read this and tested for my app also wherein I would have the same problem in coming days. Any better way of overcoming this problem other than persisting the session manually. Regards, Gurmeet -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 4:08 PM To: [EMAIL PROTECTED]; Tomcat Users List Cc: Peter Tornberg Subject: Re: Session lost when switching from https to http in Tomcat 4 You are right Manuel, Tomcat 4.0.2 using SSL unfortunately always sets a Secure flag on JSESSIONIDs, which do not (depending on browser) allow you to do this https-http switch. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6983 A Macintosh using IE 5 cannot even obtain a _standard_ SSL jsession due to this. This is why I have requested this behavior to become an option. The option would actually disable a cookie-RFC compliant feature, but so what, if you cannot get things to work? cheers, Anders - Original Message - From: Manuel Mall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 11:17 Subject: Session lost when switching from https to http in Tomcat 4 Has the session semantic changed between Tomcat 3 and Tomcat 4? We have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. This works fine under Apache 1.3.22 with Tomcat 3.2.1 connecting using ajp12. After upgrading to Tomcat 4.0.3 now using ajp13 the session appears not to be preserved between https and http, ie. after switching back to http the request.getSession(false) call returns null. This seems to indicate that the session tracking mechanism has changed between Tomcat 3 and Tomcat 4. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 4 I might have missed? Thanks Manuel -- 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] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Tomcat 4.0.2 Macintosh Bug VERIFIED and KILLED
In: org.apache.catalina.util.CookieTools.java a flag Secure is added to JSESSIONIDs for SSL sessions. This is incompatible with Mac IE 5.0. RFC-compliant though What is the *future* way to handle this? We of course patched our TC. Open Source is just GREAT! Best Regards Anders Rundgren -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Catalina Cookies URL Encoded? Tomcat 3 Not?
Leonard, Its a bug in Tomcat 4. We also had to make the work-around you suggested. I depends also on if you use Warp or AJP connectors. There are unfortunately other cookie-related bugs in TC 4 as well. Some due to the fact the the browser manufacturers do not follow the current RFC too well. Anders - Original Message - From: Megliola, Leonard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, March 17, 2002 22:19 Subject: Catalina Cookies URL Encoded? Tomcat 3 Not? Hello, I recenly upgraded to Tomcat 4 and found that some of my cookie parsing code no longer works. It seems that with Tomcat 3 colons come through as colons in my cookie values but in Tomcat 4 they are URL encoded (%3A). Is this standard behavior in Tomcat 4 or a bug? Should I modify my code to URL decode before processing now or expect a bug fix? If this is the appropriate behavior is this conditional behavior, meaning are there situations where URL encoding will not take place? Thank you, Leonard -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Multiple SSL ports
Michael, I'm up to my eyeballs in SSL-problems using TC but maybe I can help. You have: https://host:443/ https://host:444/ This indicates that you have two _different_ applications and they do not share session content. To let them share session requires authentication mechanisms that is not likely to be a part of the current TC. If they are one app I see no point in having two ports. But maybe you mean that you use http and https to the same app. That should work. At least if you step-up from http to https, it works for me at least. The other-way-round should be disabled by browsers for security reasons although IE don't care... Anders - Original Message - From: Michael Welsh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 13, 2002 14:37 Subject: Multiple SSL ports Greetings, I have a server running Apache 1.3.22 and Tomcat 3.3 on Solaris 8. Up until now my Tomcat configuration included just one webapp and it used the standard port 443 for SSL (through Apache). That all works really well. Now I am trying to integrate a second webapp, and therefore a second context that will use a different SSL certificate. This is no problem for all http requests since they all use port 80, but https ports are a different story. Since 443 is already used for the first context, I am forced to use a different port for the second, and to include it in my URL (i.e. https://www.xxx.com:444/). That too works fine now that I got it set up correctly in my Apache configuration file. So here's the problem: The client will surf through the site and collect his set of session objects (cart, etc.), but when it comes to to activate the SSL, Tomcat seems to look at that URL as if it were a new user, therefore assigning it a new session. The client looses his cart. Any ideas of how I can make Tomcat not pay attention to the port for the server information? any help would be a blessing Michael Welsh -- 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: Multiple SSL ports
Michaeal, So your client is stepping up from http://host/ to https://host:444/ after first getting a session in the http mode? I tried this on my own setup and at least from http://host/app to https://host:443/app I kept the session going. Note that I deleted the c**p in httpd.conf about broken IE and kept keep-alive. This worked with both IE 5 and NS 6.2. Regarding multiple SSL servers, the easiest is to give them unique IP addresses. IIS (which I also use) requires this I believe. But this may not be an option for you? /anders - Original Message - From: Michael Welsh [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Wednesday, March 13, 2002 17:44 Subject: Re: Multiple SSL ports Anders, Thanks for getting back to this. Here is a better way of looking at what is going on: I already have an app that uses https on port 443 and uses it's own SSL certificate. Since it is on the standard 443 port I don't need to tack it on to the server name when I need to activate SSL. Now I have another app that will use a different certificate. Since Apache virtual hosting doesn't allow fo named virtual hosting on SSL (I verified that with Verisign), the only way to do things is by using a different port number. I therefore tack change my server name from http://host/ to https://host:444/ when I active SSL. This works quite well for everything that concerns https. The problem that I am having is that Tomcat assigns a new session ID to the client when this transfer is made, and any session objects that client had are lost. Can you tell me why this is happening or how I can get around it? In exchange I will grant you eternal consciousness. Michael Anders Rundgren wrote: Michael, I'm up to my eyeballs in SSL-problems using TC but maybe I can help. You have: https://host:443/ https://host:444/ This indicates that you have two _different_ applications and they do not share session content. To let them share session requires authentication mechanisms that is not likely to be a part of the current TC. If they are one app I see no point in having two ports. But maybe you mean that you use http and https to the same app. That should work. At least if you step-up from http to https, it works for me at least. The other-way-round should be disabled by browsers for security reasons although IE don't care... Anders - Original Message - From: Michael Welsh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 13, 2002 14:37 Subject: Multiple SSL ports Greetings, I have a server running Apache 1.3.22 and Tomcat 3.3 on Solaris 8. Up until now my Tomcat configuration included just one webapp and it used the standard port 443 for SSL (through Apache). That all works really well. Now I am trying to integrate a second webapp, and therefore a second context that will use a different SSL certificate. This is no problem for all http requests since they all use port 80, but https ports are a different story. Since 443 is already used for the first context, I am forced to use a different port for the second, and to include it in my URL (i.e. https://www.xxx.com:444/). That too works fine now that I got it set up correctly in my Apache configuration file. So here's the problem: The client will surf through the site and collect his set of session objects (cart, etc.), but when it comes to to activate the SSL, Tomcat seems to look at that URL as if it were a new user, therefore assigning it a new session. The client looses his cart. Any ideas of how I can make Tomcat not pay attention to the port for the server information? any help would be a blessing Michael Welsh -- 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]
How do you achieve persistant Tomcat connections?
Dear all, I have no success in getting my TC 4.0.2 under apache and ajp1.3 returning persistant TCP connections in spite of using up-to-date (HTTP 1.1) browsers. Any clues to this (except for reprogramming the application) would be *very* appeciated. /anders -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: 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]
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]
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]
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]
Re: IE 5 on Mac is incompatible with TC 4?
Ralph, Thanx for your advice but this is likely to be a bug in TC 4.0.2 that cannot be too hard to fix. I just found-out that it only affects SSL, which I guess is the reason no one has seen it before. URL rewriting is a possibility but our app will get ugly, so I prefer to launch without Mac. Anders - Original Message - From: Ralph Einfeldt To: Tomcat Users List [EMAIL PROTECTED] Sent: Friday, March 08, 2002 13:11 Subject: AW: IE 5 on Mac is incompatible with TC 4? I think they best way you can solve this problem, is to use response.encodeUrl() on all links to enable the session tracking by url. -Ursprüngliche Nachricht- Von: Anders Rundgren [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 8. März 2002 13:04 An: Tomcat Users List Betreff: 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 -- 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: IE 5 on Mac is incompatible with TC 4?
Ralph, I got the impression from your previous posts, that the browser is the source not tomcat. Well This is matter of taste. As IE 5 is the current Mac release and IE is relatively popular even by Mac-user's, I believe that TC should adopt to IE 5 rather than the revse. A *really* strange thing is that persistant cookies work. But the problem is only related to SSL. /anders -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: IE 5 on Mac is incompatible with TC 4?
Randy, I don't know if Mac IE 5 is doing something *outside* of the cookie-specification (which governs this rather than the servlet specification), but I'm pretty sure that the original Apache-server handles this differently than Tomcat. Do you know any Apache SSL-site using session-cookies that I could test? /anders - Original Message - From: Randy Layman To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Friday, March 08, 2002 13:19 Subject: RE: IE 5 on Mac is incompatible with TC 4? I haven't been following this thread but it seems like you are saying that Tomcat should be modified to work correctly with IE 5. The problem with that is that Tomcat is an reference implementation of a particular spec (JSP/Servlet) which dictates how things have to work - it is the reference by which all others are implemented. It can't change to accommodate bugs or special features of client software. Randy -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Friday, March 08, 2002 7:51 AM To: Tomcat Users List Subject: Re: IE 5 on Mac is incompatible with TC 4? Ralph, I got the impression from your previous posts, that the browser is the source not tomcat. Well This is matter of taste. As IE 5 is the current Mac release and IE is relatively popular even by Mac-user's, I believe that TC should adopt to IE 5 rather than the revse. A *really* strange thing is that persistant cookies work. But the problem is only related to SSL. /anders -- 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: IE 5 on Mac is incompatible with TC 4?
Ralph, at this stage we can just guess as it does not *have* to be a browser bug. Particularly as other web-servers most likely handles this differently. I have verified that IIS does this OK but that was hardly a surprise :-). I will now perform some deeper investigation by writing a small servlet that just spews out header contents to see what differs. Just done! No cookies are sent from IE which means that TC is likely to send something IE 5 Mac does not understand. Secure is an addition that TC offer but not IIS. Secure is though RFC-compliant so maybe IE 5/mac *is* broken. TOMCAT --- Date: Fri, 08 Mar 2002 15:00:42 GMT Server: Apache/1.3.23 (Unix) mod_ssl/2.8.6 OpenSSL/0.9.6 mod_jk/1.2.0 EXPIRES: Thu, 01 Jan 1970 00:00:00 GMT Set-Cookie: JSESSIONID=7C1F8E3DD950780CA775B3EB3AE74D16;Path=/BuyerASP;Secure Connection: close Content-Type: text/html IIS --- Server: Microsoft-IIS/5.0 Date: Fri, 08 Mar 2002 15:13:12 GMT Connection: Keep-Alive Content-Length: 1443 Content-Type: text/html Expires: Fri, 08 Mar 2002 15:12:12 GMT Set-Cookie: ASPSESSIONIDGQQGGWNY=INDLBBEAKPOBKEMFDDDHAFCM; path=/shop Cache-control: private Anders - Original Message - From: Ralph Einfeldt To: Tomcat Users List [EMAIL PROTECTED] Sent: Friday, March 08, 2002 15:10 Subject: AW: IE 5 on Mac is incompatible with TC 4? I don't copletly agree with that. As long as you don't break specs it is possible to do something in tomcat to deal with errors in browsers. (Like missbehavior in the headers of a http request) If a browser has a bug that you can't deal with, without breaking the spec there isn't much you can do. There might also be browser bugs that you can't avoid at all. E.G. if a browser doesn't send a cookie under certain conditions, what would you suggest to change on the server side to change that. (I don't know if this happens here) P.S: In this case you don't have to alienate all Mac IE5 users because there is workaround: using encodeUrl(). Which should be used anyway, because otherwise you will alienate all users that disable cookies. (Which will be more than Mac OS 9 users with IE 5) -Ursprüngliche Nachricht- Von: Joe Laffey [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 8. März 2002 14:27 An: Tomcat Users List Betreff: RE: IE 5 on Mac is incompatible with TC 4? snip/ Who cares if it's a reference implementation? If it doesn't work with current mainstream browsers then it is useless. No company running a ecommerce site wants to alienate all Mac IE5 users. It would be idiotic, not mention bad business. Tomcat must work with all current mainstream browsers (at least NS and IE) on all all major platforms for it to be useful. Typical sers do not upgrade their browsers. So everything else must be upgraded to work with them, bugs and all. snip/ -- 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: IE 5 on Mac is incompatible with TC 4?
Dave, snip The system described above relies on correct behavior of cookies on the Mac in IE, and it works for us. I don't know if any behavior on the Tomcat side has changed since 4.0.1, but I would tend to doubt it. That's nice to hear :-| Why are you using a secure cookie for the session cookie? Do you need to? 1. We tested this exclusively over HTTPS. For HTTP things work OK: 2. Actually, we do absolutely nothing but request.getSession() which triggers the session-mechanism according to my fellow developer. I.e. we don't handle cookies ourselves, we rely on Tomcat's handling which has worked fine until we started to mess with Mac and IE 5. If so, you can't expect the session to remain intact across HTTP and HTTPS requests. Any browser that DOES send a secure cookie over a straight HTTP request is dangerously out of spec. Note, we don't switch between HTTP and HTTPS, but you are right in your comment. cheers, Anders -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Missing MIME-type in Tomcat 4.0.2 errors?
Hi, I got at rather funny line (HTML displayed as raw text) using Netscape 6.2.1 and it seems to be caused by a missing MIME-type in Tomcat 4.0.2 error messages. Is this a known problem? How do you change this behavior? cheers, Anders -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Same host multiple ports don't work?
Hi, In IIS I'm able to define virtual servers using the same host-name but different ports. These virtual servers have independent paths (applications) as you would expect. I can't see any similar functionality in Tomcat or am I just reading the config documents wrong??? regard, Anders R -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Clarification: Same host multiple ports don't work?
http://myhost:8000/app http://myhost:9000/app Should be possible to configure independtly, I.e. app could be different for the two ports. But the Tomcat mapping schemes does not seem to include port and host. /anders - Original Message - From: Anders Rundgren [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 22, 2002 15:50 Subject: Same host multiple ports don't work? Hi, In IIS I'm able to define virtual servers using the same host-name but different ports. These virtual servers have independent paths (applications) as you would expect. I can't see any similar functionality in Tomcat or am I just reading the config documents wrong??? regard, 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]
