[berkut]

Fair point, however I've seen no evidence Chrome is doing keep-alive on Linux or Mac OS - it always seems to send a FIN ACK after the response from the server to close the connection.

Firefox most definitely is utilising it fully, and obeys the Keep-Alive params specified, which I can't see any of the other browsers doing.

[fps_doug]

Just checked with Chromium 71 on Linux against lighttpd - keepalive works just fine, seeing html, css and js requested using the same connection. I'd also suspect something's up with your server's implementation.

FWIW, this is the reply header lighttpd sends:

    HTTP/1.1 200 OK
    Vary: Accept-Encoding
    Content-Encoding: gzip
    Last-Modified: Wed, 16 Sep 2015 08:50:41 GMT
    ETag: "713114043"
    Content-Type: application/javascript
    Accept-Ranges: bytes
    Content-Length: 9743
    Date: Fri, 08 Mar 2019 10:34:12 GMT
    Server: lighttpd/1.4.35

[pvg]

I've seen no evidence Chrome is doing keep-alive on Linux or Mac OS

That sounds like a bug with your server implementation. The web would melt down if Chrome's keep-alive support didn't work.

[berkut]

Possibly, and that's what I assumed at first, but I don't really see how: after sending the response the socket waits for more data in the form of another request from the user agent (I've tried with and without a poll / socket timeout).

Firefox does this perfectly. Chrome sends a FIN ACK in response to the response from the server, and it closes the connection its side, triggering the next recv() within the server to return 0 (or poll() to fail, depending on how I do it). But then it opens another connection after that with another request which could have been within the previous connection.

I also can't see Chrome doing it on non HTTPS websites in general when monitoring through wireguard, which is why I don't believe it's an issue with my server's implementation: I haven't actually observed Chrome utilise it at all on several computers on both Linux and Mac OS.

[pvg]

I don't know why you're seeing what you're seeing but your testing/monitoring setup sounds like it's at a bit too low level for the thing you're trying to figure out. A few basic things you might want (or should, really, if you're implementing HTTP from scratch) to try:

- Serve real content, say, a basic HTML page with a couple of external resources.

- Serve same and monitor (turn on all teh logs) with apache.

- Use the Chrome dev tools. In the network tab, right click on the column headers in the request list and enable the 'Connection ID' column. Keep in mind any modern browser will open concurrent connections in the base HTTP 1.1 case.

[berkut]

Thanks, but I've done this (although used Nginx instead).

The web server I've written is now serving several websites I'm hosting, some of which have thousands of images, so there's plenty of scope for connection re-use.

Each connection ID is different within dev tools in Chrome - although errors have 0 - (often sequential, sometimes there are huge gaps). And this is the same with HTTP websites on the net (just tried www.briscoes.co.nz and am still seeing the same thing in Chrome 72).

Using Wireshark I can see that Firefox is doing the correct thing, so I'm not sure why you think what I'm looking at is too low-level: I think it's pretty clearly something the client's doing at the TCP level to close the connection its end after its received the content length.

It may well be that I'm not sending a header Chrome's looking for, but I'm not sure what it is, as in its request it's sending "Connection: keep-alive", and the response has the same, and Firefox works fine.

It's almost like it's a client configuration or something, but I don't know what that would be, as I've tried on several machines.

[pvg]

'Too low level' is Wireshark before Chrome dev tools. I didn't know if you'd tried the dev tools since you didn't mention it. As to the other stuff, I'm not sure what portable Chrome-breaking field you emit - www.briscoes.co.nz instantly shows connection reuse on my end.

https://i.imgur.com/LJIaRac.png