Re: [Jetty-support] SSL dilemma

[Chris H. <ch...@ha...>]

Nick,

I presume you refer to your 17th Feb report ...
--------------------
Occasionally, and there seems to be no identifiable pattern, form variables
are not being posted to the server.  That is to say, when the receiving JSP
processes request.getParameter("param"), a null value is returned.  The
curious thing is that this only happens if the submit button is pressed
within a few seconds of the page being displayed at the client.  If the page
is left for five or six seconds before the submit button is pressed, the
problem goes away.
------------------
and you later added that this was when _not_ using SSL.

You also had some 'interesting' network-topology interactions :-)

I think M$ only declared that  Q831167 fixed SSL-related problems.

It's interesting that it has also fixed the above problem!

My thoughts at the time were that the 'five or six seconds'  perhaps related to
the Jetty persistent connection timeout, i.e. the problem occurred when the
request was sent using the same TCP connection.  I had been going to ask at the
time what your SocketListener timeout settings were, and about differences in
packet fragmentation strategies in the different topologies, but maybe events
overtook me.

My thoughts at the time were that these symptoms were compatible with the
hypothesis which I had at the time, namely that there was a fundamental race
conflict somewhere in the MSIE request submission process that was independent
of whether or not SSL was in use.

It was just being seen most commonly under SSL because of the different timings
in requests over established SSL Sessions.

My guess was that your particular situation was causing the race fault to
manifest when using the same (non-SSL) TCP connection, but, if the Submit was
delayed, the TCP session would have timed out at Jetty, so the browser would
have to ask for another TCP session, thus slowing the browser down so that the
race fault did not mainfest.

I guess that, until M$ goes Open Source, we will never know what the root
problem was, and whether that have truely fixed it in Q831167.

My reading of their associated Technical Note was that they thought it was
purely associated with SSL - so my fear is that they may have worked around the
symptom, rather than fix the root problem forever. I guess we may never know.

Anuyway, back to what Jetty does about this.

I'd be reluctant to suggest that Greg advertise Q831167 as a fix for non-SSL
problems, unless M$ have also said that.

You may just be lucky!

Chris


----- Original Message -----
From: "Wadge, Nick" <nic...@uk...>
To: <jet...@li...>
Sent: Monday, February 23, 2004 10:18 AM
Subject: RE: [Jetty-support] SSL dilemma


> Chris
>
> Please bear in mind that the bug introduced with Q832894 does not only
> affect SSL.  We've had problems over non-SSL which are resolved with
> Q831167.
>
> Cheers
> Nick
>
>
>
> -----Original Message-----
> From: Chris Haynes [mailto:ch...@ha...]
> Sent: 20 February 2004 19:14
> To: Jetty Support
> Subject: [Jetty-support] SSL dilemma
>
>
> Here's a dilemma:
>
> Over the last couple of years it has been known that there has been  a bug
> in
> MSIE's SSL handling - usually manifesting when people asked for multiple
> images.
> The observed result was that the SSL protocol sequence was corrupted in some
> way, raising an exception in the server's SSL layer.
>
> It was found that the problem was present if HTTP/1.1 persistent connections
> were in use over SSL.
>
> A few months ago I posted a work-around, which detected the MSIE client and
> de-persisted SSL connections. Greg subsequently incorporated this feature
> into a
> Jetty release.
>
> I think (but I can't be sure) that this work-around has the disadvantage of
> introducing an extra round-trip delay for each SSL within-page request.
>
> AFAIK, M$ have never publicly conceded the presence of the above bug.
>
> Recently M$ appears to have issued a widely-adopted update (probably the
> security update Q832894 of 2 Feb), which had the side-effect of introducing
> a
> closely-related bug: the content could be omitted from a POST request sent
> over
> SSL. This was reported by 5-6 posters to the Jetty Support list.
>
> M$ have issued a patch (Q831167 ) which is advertised as solving the
> POST-related bug.
>
> One of the support list posters (Dominique Paquin) has still been working on
> the
> original bug and has reported (18 Feb) that Q831167 seems also to solve the
> original 'multiple SSL image' bug.
>
> So it looks as if Q831167 may solve _both_ SSL-related problems.
>
> So it seems that the de-persist work-around is not required for clients
> having
> Q831167 installed. I don't think this patch advertises its presence in the
> UserAgent request header (but I have not checked), so I don't think we could
> devise a run-time UA-aware switch for the work-around
>
> Dilemma:  When, if at all, to remove the performance-degrading SSL
> work-around
> from Jetty.
>
> One of the problems is that no one was ever able to post a stand-alone test
> case
> for either bug, so we have no means of testing that the patch really has
> solved
> both problems.
>
> We also cannot be sure that Q831167 can be applied in isolation. It is
> possible
> that both Q832894 and Q831167 have to be applied in series.
>
> It would be possible to remove the work-around now, after informing the
> lists.
> Anyone then having SSL problems would be advised to install the Q831167
> patch.
>
> Should this be done?
>
> Or should the work-around now be made a configurable option, so that
> individual
> sites could make this decision for themselves?
>
> Chris
>