The peer can't receive the SSL close_notify or the TCP FIN until it has received all the pending data from the sender. Conversely, if there is any TCP data in flight back to the sender when the peer receives the close_notify and FIN it will not be discarded. The response close_notify and FIN can only be sent after any pending data.
EJP -----Original Message----- From: Vincent Goelen [mailto:goel...@gmail.com] Sent: Tuesday, 18 December 2012 3:52 AM To: Tomcat Users List Subject: Re: Tomcat 7 SSL Session ID If you run the test.jsp page.. When you send a request and interrupt it while it's processing.. For example by pressing the stop loading button immediatly after sending the request or by pressing the refresh button fast enough.. When you look what happens then: the SSL connection sends close notifies which should make sure no more data is sent over the connection.. This does happen, the client has sent it's TCP close packet and after that it receives application data from the server while it shouldn't do that according to the ssl specs.. When the client receives this application data after the connection is already closed, it sends a TCP rst packet causing an invalidate of the server... This problem has nothing to do with not using the exception handling but seems to me more a problem of Tomcat's priority of TCP specs in front of SSL specs 2012/12/17 Martin Gainty <mgai...@hotmail.com> > > Session.SessionTrackingModelListener.java contains > context.setSessionTrackingModes(modes); with no exception handling /** > * @param sessionTrackingModes > * @throws IllegalArgumentException > * If sessionTrackingModes specifies > * {@link SessionTrackingMode#SSL} in combination with any > other > * {@link SessionTrackingMode} > * @throws IllegalStateException > * If the context has already been initialised > * @throws UnsupportedOperationException > * @since Servlet 3.0 TODO SERVLET3 - Add comments > */ > > public void setSessionTrackingModes(Set<SessionTrackingMode> > sessionTrackingModes) throws IllegalStateException, > IllegalArgumentException; Moral of the story..always catch declared > Exceptions where is the jsp you test with? > Martin > ______________________________________________ Please do not alter or > otherwise disrupt this communication..thank you > Date: Mon, 17 Dec > 2012 09:47:09 +0100 > > Subject: Re: Tomcat 7 SSL Session ID > > From: goel...@gmail.com > > To: users@tomcat.apache.org > > > > Hey, > > > > http://users.telenet.be/goelenv/SSLTomcat.zip > > > > in this link you can find a netbeans project that will generate the > fault.. > > The index.html page will send requests to the index.jsp page, the > > thread sleep is just to emulate a long process of a request (like > > database > things, > > etc) > > > > Kind regards, > > Vincent > > > > 2012/12/10 Christopher Schultz <ch...@christopherschultz.net> > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA256 > > > > > > Martin, > > > > > > On 12/10/12 10:22 AM, Martin Gainty wrote: > > > > we need to get your architect into this discussion > > > > > > > > Why is your code implementing 2 different Connections to > > > > accomplish this functionality when one Connection at a time will > > > > suffice? > > > > > > You have no idea what you are talking about. There is only one > > > connection. There is only one connector. The OP is reporting that > > > his SSL session id expires long before he is expecting it to expire. > > > > > > This has nothing to do with webapps and connectors except he > > > happens to have a connector and a webapp. > > > > > > - -chris > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > > > Comment: GPGTools - http://gpgtools.org > > > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > > > > > iEYEAREIAAYFAlDGXhIACgkQ9CaO5/Lv0PDwtQCgk63c5ZUVojVhdgVpHpF5IMkX > > > 3lYAoKPCpNeo8lEquukN/BRxPjuFfl1E > > > =tdIg > > > -----END PGP SIGNATURE----- > > > > > > ------------------------------------------------------------------ > > > --- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
