Eduard Urbach

I see, then it all makes sense now. It depends on the client-side implementation for key retrieval.

The numbers are definitely wrong. Take a look at [Go](https://web-frameworks-benchmark.netlify.app/result?l=go) and compare it with the 2024-12 results. I have no clue why my own library is the only one showing...

But why would somebody send "Connection: close" and immediately follow up with _another_ request on the same connection? I believe that's what's happening here in the benchmarks and this combination...

> > The benchmark seems to violate this rule > > These rules should work for real-world applications. But in the real world, no web server receives thousands of requests...

> [@akyoto](https://github.com/akyoto), why are you sure that the client is trying to send requests to an already closed connection? It's based on the numbers I see. My reverse-proxy targeted web...

> > My reverse-proxy targeted web server ignores "Connection: close" > > This is a problem on your web server's side. It's clearly not working according to the HTTP rules...

The golden rule of network communications is to never trust the other side. It doesn't matter what the server does - the client can't trust the server and it needs...

@waghanza The problem is that we are talking about 2 different things here. You talk about the **testing methodology**. Nobody here has a problem with your testing methodology. Sure, we...

> As I understand, the tool (wrk) send http request after closing the connection ? It doesn't close it after reading the final response message, and that's precisely the problem....

> Only one local client, a Synology DiskStation, picked up an IPv6 address from the local subnet automatically. I didn't have to change anything, it just appeared in the list...