Just to list the possible sources: - Tomcat doesn't send the cookie Unlikely, as it works with other browsers - Tomcat send it in a format that this version of ie doesn't recognize Two variants for this - The header contains/misses something that makes this version of IE fail. - Something tomcat creates garbage on some headers when encrypting it - This version of IE doesn't send the cookie Nobody but MS can do anything about it. - This version of IE sends the cookies in format that tomcat doesn't recognise - The header contains somthings that hinders tomcat to decrypt the cookie correctly - The decrypted header contains somthings that hinders tomcat to read the cookie This doesn't mean that it must be a fault of the IE. It's possible that tomcat has a bug that just has an effect if certain (legal) bytes are present in the header.
As this happens with SSL, it's hard to debug. (Watching the network to see who sends which cookies doesn't work) The only point where you can debug is the tomcat sources to look at the tomcat generated header just before it is encryped and to look at the IE generated header directly after it is encryted. To do that you would have to look at the raw data that was sent. To look at the header with the servlet API can be to late. If tomcat somehow didn't recognize a header you won't know if it wasn't sent or if tomcat just didn't recognizee it. > -----Urspr�ngliche Nachricht----- > Von: Anders Rundgren [mailto:[EMAIL PROTECTED]] > Gesendet: Freitag, 8. M�rz 2002 17:37 > An: Tomcat Users List > Betreff: 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]> > > > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
