bump(main/openssll): 3.5.0

[TomJo2000]

Updates openssl to 3.5.0

• Clean up the shellcheck warnings in the build script
• Set a maintainer

Updates sslscan to 2.2.0

• Depend on openssl (>= 3.5.0)

[!IMPORTANT] Essential package update checklist:

• [x] builds locally
• [x] builds on CI
• [ ] tested on-device
• [ ] SO versions verified
• [ ] Package completeness verified
• [ ] Reverse dependencies tested/rebuilt if necessary

• closes #25056

[remittor]

mrhttp also non realistic implementation: https://github.com/TechEmpower/FrameworkBenchmarks/issues/9055

[joanhey]

Now the devs of the framework decide if it's realistic or not.

We need to implement more tests before start the benchmark !!

https://github.com/TechEmpower/FrameworkBenchmarks/issues/9440#issuecomment-2518472173

[p8]

The template is OK to cache, but the response for the fortunes is NOT OK.

I wonder if we should make fortunes response dynamic to prevent this. Maybe store more fortunes in the database and pick random fortunes, similar to the query test?

[joanhey]

Validate response status codes #9605

[joanhey]

Shouldn't pre-computed HTTP headers trigger "Stripped" classification? #8205

[joanhey]

@p8 https://github.com/TechEmpower/FrameworkBenchmarks/issues/9578#issuecomment-2656955552 https://github.com/TechEmpower/FrameworkBenchmarks/issues/6529 https://github.com/TechEmpower/FrameworkBenchmarks/issues/6788 https://github.com/TechEmpower/FrameworkBenchmarks/issues/6883

[p8]

The aspnetcore framework precomputes the header length as well:

https://github.com/TechEmpower/FrameworkBenchmarks/blob/c82a834c5e8aeae14c8203cc05beaaa18dcc7cfc/frameworks/CSharp/aspnetcore-mono/PlatformBenchmarks/BenchmarkApplication.Json.cs#L14-L18

https://github.com/TechEmpower/FrameworkBenchmarks/blob/c82a834c5e8aeae14c8203cc05beaaa18dcc7cfc/frameworks/CSharp/aspnetcore-mono/PlatformBenchmarks/BenchmarkApplication.Json.cs#L12

https://github.com/TechEmpower/FrameworkBenchmarks/blob/c82a834c5e8aeae14c8203cc05beaaa18dcc7cfc/frameworks/CSharp/aspnetcore/src/Platform/BenchmarkApplication.Plaintext.cs#L13-L16

[remittor]

aspnetcore

image

https://github.com/TechEmpower/FrameworkBenchmarks/blob/c82a834c5e8aeae14c8203cc05beaaa18dcc7cfc/frameworks/CSharp/aspnetcore/src/Platform/BenchmarkApplication.Json.cs#L19-L23

The benchmark uses a custom implementation of the Date header generation:

https://github.com/TechEmpower/FrameworkBenchmarks/blob/c82a834c5e8aeae14c8203cc05beaaa18dcc7cfc/frameworks/CSharp/aspnetcore/src/Platform/BenchmarkApplication.Json.cs#L25-L30

But in fact, we should test the implementation that comes with the original framework:

https://github.com/dotnet/aspnetcore/blob/main/src/Servers/Kestrel/Core/src/Internal/Http/DateHeaderValueManager.cs

https://github.com/dotnet/aspnetcore/blob/8645583a97fa8140da0a588bbd00c5e9cf13983c/src/Servers/Kestrel/Core/src/Internal/Http/HttpProtocol.cs#L1263-L1269

[cyrusmsk]

Please, no more http: length hard encoded.

No more template response cache !!! The template is OK to cache, but the response for the fortunes is NOT OK.

#9560 (comment)

It will be really nice

Unfortunately, it will be a massive reduction in a number of approved frameworks. A lot of solutions just use dirty hacks to show higher values.

People sometimes are protecting this position with "Nginx-like proxy will be a protection layer and our server with logic can do whatever we want and we don't care about proper HTTP implementation"

[Dmole]

If you need a Nginx proxy to present a proper HTTP implementation, then the Nginx proxy needs to be in the test (welcome to the bottom of the charts, lol).