On Tue, 17 Aug 2004, QM wrote: | On Tue, Aug 17, 2004 at 05:33:00AM -0700, Cott Lang wrote: | : One problem with that is you can still have the session hop servers | : since the Local Director can't match up cookie based mappings to SSL | : session mappings, since it can't read the cookies from SSL connections, | : and can't read non-existant SSL session IDs from non-SSL sessions. | | I may have dreamt this =) but I thought you could have the | LocalDirector/F5/whatever handle SSL for you, then send plaintext | traffic back to the Tomcat containers. (This is effectively what | people do when they put a web server in front of Tomcat using jk/jk2.)
That's exactly what I meant. Have a good read on the LD and BigIP (or whatever it was) and the Linux-based approach, I think you might find something in there that magically solve those problems. | | That would grant the LD/F5/etc access to plant their own cookies and | otherwise determine which client was bound to that Tomcat. Yes. That's also what I referred to when mentioning "SSL Session" - see, the SSL layer in effect creates a session with the client, and one can thus use this to do sessioning/sticking with - AT LEAST this works when you use client certificates, but I'm not totally sure how this goes when there is no client certificate. Still the browser and server has to do some negotiation of what session key they'll use - and this is what I believed was the key to session-keeping-aspect of SSL. | | -but again, this is all hazy in my memory, so I fear I may have dreamt | it all... I'm pretty sure of this. This is supposed to be one of the nice things with these dedicated clustering boxes: "HW" SSL.. Endre --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
