"Connection:" header should default to 'keep-alive' in HTTP/1.1 on the regular Client API

[dkeeney]

See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection

What I am getting is Connection: close which is the default for HTTP/1.0.
For HTTP/1.1 the default should be Connection: keep-alive.

================================
GET HTTP/1.1 /hi
  Accept: */*
  Connection: close
  Content-Length: 0
  Host: localhost:8050
  REMOTE_ADDR: 127.0.0.1
  User-Agent: cpp-httplib/0.5
--------------------------------
200 HTTP/1.1
  Connection: close
  Content-Length: 13
  Content-Type: text/plain
body: Hello World!

[yhirose]

@dkeeney, thank you for the feedback. Are you experience it even when using 'Keep-Alive' Client API?

https://github.com/yhirose/cpp-httplib#keep-alive-connection

cli.set_keep_alive_max_count(2); // Default is 5

std::vector<Request> requests;
Get(requests, "/get-request1");
Get(requests, "/get-request2");
Post(requests, "/post-request1", "text", "text/plain");
Post(requests, "/post-request2", "text", "text/plain");

std::vector<Response> responses;
if (cli.send(requests, responses)) {
  for (const auto& res: responses) {
    ...
  }
}

If it doesn't work on your machine, please let me know. At least on my unit test suite, it works. We can control the max keep alive count with set_keep_alive_max_count.

When it comes to the regular Client API such as http::Client cli("host", 1234); cli.Get("/hi");, unfortunately it cannot keep the connection by design, because the client cannot know when the connection should be closed. That's why it sets 'close' to the connection header.

This is a similar behavior as curl does. Hope this explanation helps.

[dkeeney]

it cannot keep the connection by design, because the client cannot know when the connection should be closed. That's why it sets 'close' to the connection header.

That is correct for HTTP1.0 by default and HTTP1.0 with Connections: close defined. But for HTTP1.1 default and HTTP1.0 with 'keep-alive' defined the connections should be kept alive and closes after some timeout. See https://tools.ietf.org/html/rfc7230#page-50 Actually the timeout is in section 6.5 and closing is in 6.6.

The actual amount of the timeout is not specified in the RFC. But if it is even a few seconds it would be long enough for back-to-back request to occur without requiring a connection open. 10 seconds is a good number. See https://blog.stackpath.com/glossary-keep-alive/ for how it is done with the Apache server.

Technically you are not REQUIRED to implement keep-alive but I would think most people would expect it.

I was hoping to use keep-alive to see if the long delay on Windows was due to connection opening times. Maybe its something to do with how windows opens connections.

[yhirose]

@dkeeney, thank you for the detail. Yes, you are totally right! I understand the regular Client API should set 'keep-alive' to 'Connection' header. But it's difficult to implement to keep the same connection over more than one requests right now due to the defect of the regular Client API design. I would like to fix it, but it requires fundamental changes in this library. In the future, I may get back to this. Sorry for causing the inconvenience...

Because of that reason, I provided the 'Keep-Alive' Client API as a workaround. Of course, I understand that this workaround doesn't solve all the problems. @PixlRainbow has already mentioned a problem that the batch client API cannot solve in his comment #45 (comment). That's why I still cannot solve #45 (SSE (Sever-Sent Events) support on client). (As a matter of fact, it was pretty easy for me to handle 'Keep-Alive' connection in the server and the batch client APIs.)

Thank you for your consideration for the problem. :)

[dkeeney]

Yes, I understand. I have written servers in the past and I know this is not easy. And like I said, the RFC does not require the server to support keep-alive.

I will continue to look for what might be causing our 2 second delay on Windows.

[yhirose]

I'll close it for now.

[gatopeich]

Not being able to keep a connection alive renders this library unusable for many projects, including my current one.
This "keep-alive Client API" is not usable for anything beyond very basic testing of the server:

bool Client::send(const std::vector<Request> &requests, std::vector<Response> &responses)

The client should just not send "Connection: close" by default. Let the user decide what headers to send if you cannot have the logic inside.