Update HTTP, libcurl, openssl

[AiraYumi]

Are there plans to upgrade from http/1.1 to http/2 and to update libcurl and openssl?

There may not be any particular reason to update, but there is no reason to stick with unsupported libraries or old technology.

I think it needs to be updated to a better alternative.

[Geenz]

Paging @monty-linden - this seems like it's up your alley.

[monty-linden]

Not necessarily these days. But we have a ton of plans including GHIs, Jiras, gdocs, and wikis and it all begins with some infra changes and prioritization.

[AiraYumi]

We are currently working on updating OpenSSL and CURL.
Unfortunately, we do not have any compatible servers, so most textures and objects cannot be loaded.
Would it be possible for you to provide a server that supports even some of them?

[AiraYumi]

https://github.com/AiraYumi/viewer/actions/runs/19431559800

[monty-linden]

So, my warning here is the same as for old PR 3101: the HTTP pathway is performance-critical so acceptance will require more than just a PR and a merge. @Geenz and the viewer team will have to test the implications of the libcurl update. (Which we really do want and need.)

But our infrastructure isn't quite ready yet. After some recent changes, https: forms now do something other than generate errors:

$ curl -vk -o /dev/null https://asset-cdn.glb.agni.lindenlab.com/?texture_id=f0f20a8b-459e-18ac-1a3e-dce6f5320f99
> GET /?texture_id=f0f20a8b-459e-18ac-1a3e-dce6f5320f99 HTTP/1.1
> Host: asset-cdn.glb.agni.lindenlab.com
> User-Agent: curl/7.88.1
> Accept: */*
 [5 bytes data]
< HTTP/1.1 200 OK
< Last-Modified: Wed, 10 Sep 2025 13:27:07 GMT
< ETag: "9706021723cf6d019e70e7176cfdce30"
< x-amz-server-side-encryption: AES256
< Accept-Ranges: bytes
< Content-Length: 196594
< Date: Fri, 21 Nov 2025 18:43:46 GMT
< Connection: keep-alive
< Content-Encoding: binary/octet-stream
< Content-Type: image/x-j2c
<

That change is likely an accident and HTTP/2 is not yet supported.

If you really want to do local testing, one possibility is a local proxy/cache configuration. The Firestorm team publishes instructions for setting up a 'squid' proxy. Using this or an apache2 or nginx proxy should allow you to create an http2-to-http (or even http3-to-http) rewrite service. Then force the viewer under test to use your service as the CDN. This is not enough for an acceptance test, but it should be adequate for functional testing.