HTTPS still unusable in R6

HCL Domino Domino Forum
1

Hi,I am still experiencing severe difficulties in running https on R6 Servers.

Problem is, the Domino Server stops responding to https. After about 1 to 2 minutes everything goes back to normal.

I can find these entries in log file when doin a ‘http show thread state’:

20.10.2003 14:47:59 Http Worker Thread ID [4813]: Working session [1894c]: Session State [SSL Handshake] :

There are a couple of them, seems this blocks the web task.

Seems it is unsuccesful?

I can rule out any form of network problems or client problems as we can reproduce this on different servers, Mozilla and IE as clients, going direct or via Proxy and last but not least I tried server in same subnet as clients.

This prevents us from switching from R5 to R6, as R5 runs without any problem.

Another finding is:

If I prevent the server from caching SSL session keys by

SSL_RESUMABLE_SESSIONS=1

it makes the situation even worse.

Then it’s nearly impossible to load any page succesful.

Btw we are not alone, as I have feedback from other users which have exactly the same problem.

OS I tried is Redhat 7.2 and 7.3, latest errata applied.

Any help is greatly appreciated.

Thank you

Rainer

2

Subject: HTTPS still unusable in R6

I think we have similar problems as described by Rainer (but we are running 2 Domino 6.5.3FP1 Servers on Win32, previously 6.5 with the same problems).

Any news or even a solution on that one?

3

Subject: Identified: HTTPS still unusable in R6

25.11.05

Sometimes this problem is still there on our servers, and we tracked it down to some sub-versions of IE 6. When the problem occurs, SSL handshaking blocks all HTTP threads, so other users requests are stopped from being processed as well.

This only happens if those “special” IE versions are accessing the domino server over a proxy (squid, in our case), regardless which HTTP setting is used (1.1 or not). Another thread describes the same problem.

I found out, that with “HTTPQueueMethod=1” (available in 6.5.4) the problem still exists, but is a little bit harder to produce. Furthermore, IE-Patch Q831157 did help for some clients, not for others.

While debugging the domino threads with “tell http debug session on”, it became apparent that exactly the blocked threads did not log to those ht*.log-files, which makes it nearly impossible to find out the user which is causing the overall server blockade.

Since we now have a 100% reproduceable system setup, we will further investigate this problem. Since this is proxy-related, maybe there is a configuration setting to avoid those issues.

13.04.05

We found out that it indeed seems to be a problem with SSL, IE6 and Domino 6.x.

We had only 1 HTTP User session and this user worked with HTTP 1.0 which caused the problem of hangs/incomplete page loading almost immediately.

We switched DNS to our secondary server with the same config and the problem was the same. After telling this particular user to switch to HTTP 1.1, the problems were gone. With HTTP 1.1, requests (pics, css etc) are bundeled in one or a few requests to the server. But there are some HTTP 1.0 sessions that don’t cause such issues, so I guess it may be an explicit IE-Version that causes SSL-Handshake Delay.

4

Subject: HTTPS still unusable in R6

Just for the record, we were able to produce a similar problem with any browser version on R6.5 with simple http, when starting two concurrent http requests from the browser (for instance using XmlHttpRequest objects running asynchronously - one starts an agent, so the agent runs with the web user’s access rights, the other one passes data back and forth, to ensure some form of UI access for the agent, which allows us to run a script on the server but display UI components such as dialogs, prompts, confirms, etc. in the browser).

By watching the http traffic between squid and domino’s http task (using ethereal both server- and client-side), we found out that at a certain almost reproducible point during the dialog between squid and domino http a HTTP GET is sent to the server, which isn’t even logged in the web server logs on the domino machine, and never gets answered. So after the request times out for squid, a “not found” or something similar is sent back to the browser.

There is a bug in IE documented in squid’s configuration file which prevents IE from obtaining fresh content from a http server when passing through squid. Therefore squid provides a special configuration option which forces squid not to cache anything for requests coming from IE. IMO, this has a not so nice secondary effect: even when both squid and IE are configured to allow persistent connections, squid does not keep persistent connections to the domino server. Therefore, when running through squid, all requests originating from IE (I didn’t try any other browser, since IE is used by most of our customers) are broken into requests for one single resource by squid, and forwarded on a separate connection to domino http. It seems that under these conditions, at some point which is pretty much the same, given a specific scenario for reproducing the bug, domino http is not able to handle the request, and does not even log it (i.e. for resources being retrieved in a particular order, at pretty much the same point in the list of resources, a GET is issued by squid but this GET does not get serviced or logged by domino).

Because I can see no reason why Domino should not respond to a legitimate GET request, I suppose it is Domino who has a bug in responding to too many requests in a short period of time, or it has a problem handling lots of connections in a short period of time, or something like this.

Any feedback would be highly appreciated.

5

Subject: RE: HTTPS still unusable in R6

We still have this problem with 6.5.6, but now even worse. See , we have a PMR open for this, I’ll update the info there as soon as we get a response from support.