I wrote a simple server using socket API in C under linux which listens at port 80 on localhost. Now when I send a request from the browser google chrome to the program it r
It seems that if chrome can not fetch favicon (received 404 from me) it still opens the second connection for the favicon request but does not actually request it. looks like a bug (still). 'caching' gone wrong maybe aka cache ('i already received nothing the previous time') check is done after the conn is already open?
I had empty tcp packet sent by Chrome to my simple server before normal html GET query and /favicon after. Favicon wasn`t a problem but empty tcp was since my server was waiting either for data or for connection to be finished. It had no data and wouldn't release connection for 2 minutes. So thread was hanging for 2 minutes.
In related question I found a useful link saying it may be caused by "Predict network actions to improve page load performance" setting. I tried turning off prediction settings one by one and it worked. In chrome version 73.0.3683.86 (Official Build) (64-bit) this behavior was caused by chrome setting "Use a prediction service to load pages more quickly" turned on.
So just go to setting -> advanced -> privacy and security -> Use a prediction service to load pages more quickly and turn it OFF.
I am currently writing small async web server on Mono/.NET 4.0 and noticed the same thing. Chrome opens two TCP connection, but only one is used for communication. There is no data send using that socket. Even after you stop loading webpage from browser Chrome still keeps connection alive for quite some time.
I must agree with @RomanK, as it's probably for optimizations or it's a bug, but it's not for favicon as there is not data transfered throw that connection.
It does not send any data in the seconds socket. We have our Nginx webserver logs filled up with 400 errors because this second connection is closed before sending any data/actual_HTTP_request to the server. Opens the first connection, opens the second immediately then uses the first one and waits till the second one dies.
Here is a non-verbose dump about the second connection
No. Time Source Destination Protocol Length Info
20227 38.688849 89.ZZZ.TTT.208 80.XX.YYY.186 TCP 66 1758 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1440 WS=2 SACK_PERM=1
20228 38.688870 80.XX.YYY.186 89.ZZZ.TTT.208 TCP 66 80 > 1758 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=128
20256 38.752121 89.ZZZ.TTT.208 80.XX.YYY.186 TCP 60 1758 > 80 [ACK] Seq=1 Ack=1 Win=65536 Len=0
26351 50.565758 89.ZZZ.TTT.208 80.XX.YYY.186 TCP 60 1758 > 80 [FIN, ACK] Seq=1 Ack=1 Win=65536 Len=0
26352 50.565830 80.XX.YYY.186 89.ZZZ.TTT.208 TCP 54 80 > 1758 [FIN, ACK] Seq=1 Ack=2 Win=5888 Len=0
26396 50.657612 89.ZZZ.TTT.208 80.XX.YYY.186 TCP 60 1758 > 80 [ACK] Seq=2 Ack=2 Win=65536 Len=0
To me it only happen if I write/paste to chrome url field. It is never triggered from anchor tag. If you log url of request you can see it is sent two times.
My was /users. I added consloe.log() in code (node server) and you could see /users appear twice. And since i was not logged in app I would get double notification messages.
This example can reproduce it:
Script 1 name: redirect.php
<?php
session_start();
$_SESSION['x'][] = 'This will show only once';
header('Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0, max-age=0');
header('Location: /to.php');
Script 2 name: to.php
<?php
session_start();
if (isset($_SESSION['x']))
foreach ($_SESSION['x'] as $x) {
echo $x . '<br>';
}
unset($_SESSION['x']);
So if you copy paste "SERVERNAME/redirect.php" in url field eventualy you get doubled messages.
I had a similar issue with my node server. It is due to the following bug in Chrome. In summary, Chrome is sending a request for a favicon on every request. As, is likely, you aren't sending a favicon back, it requests one after every legitimate request.
Firefox, and most other browsers, also send out a request for a favicon when they first connect, but cache the result i.e. if there isn't a favicon returned first time, they don't keep trying - which is why you're only seeing a single request from Firefox. It seems Chrome is unfortunately a little too persistent with its favicon requestiness.