Forum

Hi Hugo

Would you have any idea why www.hiawatha-webserver.org could cause issues to windows 7 internet explorer?

IE11 sometimes wait about 10 seconds a response from: https://www.hiawatha-webserver.org
it doesn't happens with Firefox even if i force reload and disable Firefox DNS cache, using the same network connection and settings
Eventually IE11 loads the page but it seems it is trying to resolve something unsuccessfully in the period until it reaches some timeout

I am connecting in an automated way to hundreds of websites and www.hiawatha-webserver.org is the only one that is causing me such weird issue

I obviously thought about the DNS cache and disabling it in Firefox slows down the access by a few ms but not by 10 sec.

Thanks if you have some idea which direction I should look at

I was wondering if it has something to do with the way SNI is handled in IE11 vs Mozilla. I am running the latest updates with Win7x64 and IE11 supports SNI.
I have also done some tests with other SNI sites (https://sni.velox.ch/ - server running Apache with OpenSS TLSv1.2 AES128-SHA256 SNI) and have no slowdown with IE11.
Something confusing to me about IE11 with hiawatha-webserver.org is that in the summary it says the key is ECDH 256 and in the details RSA 2048. It doesn't happen with the other sites i have tested and I don't know what this difference between the 2 screens means for your server.

I have no idea. I tried myself with IE11 on Windows 7, but it all works fine. Perhaps Fiddler [www.telerik.com] can shed some light on this issue? Can you make an exact copy of the HTTP request that IE11 sends? Perhaps I can use it to reproduce your issue.

About ECDH and RSA, those are different ciphers for different usage. ECDH is for key exchange and RSA is for signing. I don't know what you mean with 'summary' and 'details', but I don't think this all is related to the cause of your issue.

with Fiddler I see a very long TCP/IP time, see below
****
GET https://www.hiawatha-webserver.org/latest HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-GB
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Host: www.hiawatha-webserver.org
DNT: 1
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: WebsiteSessionID=4466kqecrnh13tvmgr6vt957t5
****
Request Count: 1
Bytes Sent: 353 (headers:353; body:0)
Bytes Received: 397 (headers:394; body:3)

ACTUAL PERFORMANCE
--------------
ClientConnected: 17:55:36.520
ClientBeginRequest: 17:56:32.150
GotRequestHeaders: 17:56:32.150
ClientDoneRequest: 17:56:32.150
Determine Gateway: 0ms
DNS Lookup: 0ms
TCP/IP Connect: 21061ms
HTTPS Handshake: 46ms
ServerConnected: 17:56:53.210
FiddlerBeginRequest: 17:56:53.257
ServerGotRequest: 17:56:53.257
ServerBeginResponse: 17:56:53.382
GotResponseHeaders: 17:56:53.382
ServerDoneResponse: 17:56:53.382
ClientBeginResponse: 17:56:53.382
ClientDoneResponse: 17:56:53.382

Overall Elapsed: 0:00:21.231

RESPONSE BYTES (by Content-Type)
--------------
~headers~: 394
text/plain: 3

Overall Elapsed: 0:00:52.338

RESPONSE BYTES (by Content-Type)
--------------
~headers~: 183

That all looks normal. I get a lot of visits from IE11 / Windows 7 users. No complaints so far. My guess is that there's something wrong with your computer. Could that be the case?

Yes I have extended the tests to other computers and other networks.
The thing is that today I can't reproduce the issue on any computer, the 21 sec delay I almost systematically had over the weekend - exclusively with hiawatha server - has disappeared. I can't explain what happened. It could be on my ISP side I suppose, i haven't changed anything on my side.

Could it be that you are using IPv6 to connect to the internet? There were some IPv6 connectivity issues with my server / ISP (still don't know what and where the cause was). Could it be that your computer first tried IPv6 and when that failed, it used IPv4?

Yes indeed I have IPv6 activated and according to my ISP, an IPv6 connection is initiated first whenever possible and falls back to IPv4 if it fails.
It sounds like we are in the good direction.
Next time I can try to force IPv4 first to check if it solves the problem.

I have been testing my connection to hiawatha-webserver twice a day and haven't encountered any issue this week. The topic can be closed. I will test specifically the IPv6 aspect next time if any. Thanks for your decisive help on this one Hugo.