HTTP 1.1 use by default persistent connections

[joanhey]

Hi, reopening the discussion about #834.

Now the HTTP server returns always the Connection: keep-alive that is NOT necessary in HTTP 1.1, 2 and 3.

We maintained it for faster HTTP 1.0 clients, that almost nobody use.
And the majority of clients and users have the penalty of that unnecessary extra header, that reduce performance and increase bandwidth of each request.
Also this header is added to the hosting bandwidth bill and the server is less eco friendly :).

I think that is better by default than don't send this header, and add property for HTTP 1.0 enabled that add this header, to anybody that need it.
Similar to now we have with the reuseport option now.
EDIT: better a property in Workerman\Protocols\Http::$http10_persistent .

Thank you.

[joanhey]

Perhaps will be easier and more useful, to create Workerman\Protocols\Http::$default_headers.
By default empty string '' or array [].

And there anybody can add the Connection: keep-alive if they use HTTP 1.0.
But we can add more headers, than we want in each request:

• Server
• Cache-Control
• Allow
• Content-Language
• Date
• Vary
• X-anything
• ...

PD: if we can modify one header of the default in our code it'll be better.

[walkor]

Some benchmarking tools default to HTTP/1.0, such as ab, which I often use. I don’t want to add code to detect if the request is HTTP/1.0 and then decide whether to include Connection: keep-alive, as it wastes unnecessary performance. If we remove this header by default, we would need to check when to add it back in the response, which increases complexity and developer cost. I think keeping the current behavior is better.

[joanhey]

The other option is very useful Workerman\Protocols\Http::$default_headers.

Now we need to add the headers for each endpoint, of course we can create an array to add all, but still we need to add it in each endpoint.

[walkor]

I don't plan to expose mechanisms like Workerman\Protocols\Http::$default_headers to developers, as it would unnecessarily increase the learning curve.
Additionally, this approach would raise the complexity of header handling in the framework, requiring us to deal with header merging logic and potential CRLF Injection (HTTP Response Splitting) risks if developers fail to properly filter \r\n characters.