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
> > >
> > >
>
>

Reply via email to