Megapahit's fork of the Second Life viewer. https://www.megapahit.org/viewer.git/atom?h=cef_147 2025-07-03T05:36:50Z 2025-07-03T05:36:50Z Erik Kundiman erik@megapahit.org 2023-07-29T04:58:51Z urn:sha1:d6eb08d0740c30eed00bd600091d60128a6d079a This is cherry-picked from an old commit which was reverted before, but modified so that it only affects the platform that has to use system libcurl 8 (only Windows ARM64 so far). System libcurl, which is typically newer, doesn't accept when SL server responses with an invalid Content-Encoding value (usually some value that's probably meant to be put as the Content-Type value), that we'd get "unrecognized or bad HTTP Content or Transfer-Encoding" https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding A way to fix this would be to just not expect decompressed contents, by letting libcurl have the default value for CURLOPT_ACCEPT_ENCODING, which is NULL. 2024-06-07T05:57:31Z Erik Kundiman erik@megapahit.org 2024-06-07T05:57:31Z urn:sha1:b9a79fa2eb424facaec0e2a552111311c5d2bcf4 2024-05-16T05:52:40Z Erik Kundiman erik@megapahit.org 2024-05-16T05:52:40Z urn:sha1:6d51e91895a7f2435c46a876410ccc6c63fe8c82 source for viewer 7.1.7.8974243247 2024-04-29T04:56:09Z Andrey Lihatskiy alihatskiy@productengine.com 2024-04-29T04:43:28Z urn:sha1:1b68f71348ecf3983b76b40d7940da8377f049b7 2023-07-29T04:58:51Z Erik Kundiman erik@megapahit.org 2023-07-29T04:58:51Z urn:sha1:5776c0a692ad2848339d3bef9cae18032d6ad23a System libcurl, which is typically newer, doesn't accept when SL server responses with an invalid Content-Encoding value (usually some value that's probably meant to be put as the Content-Type value), that we'd get "unrecognized or bad HTTP Content or Transfer-Encoding" https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding A way to fix this would be to just not expect decompressed contents, by letting libcurl have the default value for CURLOPT_ACCEPT_ENCODING, which is NULL. 2021-09-03T19:21:29Z Mnikolenko ProductEngine mnikolenko@productengine.com 2021-09-03T19:21:29Z urn:sha1:8c7db0ad6cbdcfa7d80636ed13ba657e7189420e 2021-05-27T09:56:35Z Andrey Kleshchev andreykproductengine@lindenlab.com 2021-05-27T09:32:31Z urn:sha1:c518a8cf0f5032ad9b8e80907e2d553b1911424d CRYPTO_set_id_callback and CRYPTO_set_locking_callback are no-op in ssl 1.1.x 2020-03-25T19:28:17Z Nat Goodspeed nat@lindenlab.com 2019-12-06T21:31:49Z urn:sha1:5e7df752a66b2082d063d2c4a10bc7013d479f55 LLThread::currentID() used to return a U32, a distinct unsigned value incremented by explicitly constructing LLThread or by calling LLThread:: registerThreadID() early in a thread launched by other means. The latter imposed an unobvious requirement on new code based on std::thread. Using std::thread::id instead delegates to the compiler/library the problem of distinguishing threads launched by any means. Change lots of explicit U32 declarations. Introduce LLThread::id_t typedef to avoid having to run around fixing uses again if we later revisit this decision. LLMutex, which stores an LLThread::id_t, wants a distinguished value meaning NO_THREAD, and had an enum with that name. But as std::thread::id promises that the default-constructed value is distinct from every valid value, NO_THREAD becomes unnecessary and goes away. Because LLMutex now stores LLThread::id_t instead of U32, make llmutex.h #include "llthread.h" instead of the other way around. This makes LLMutex an incomplete type within llthread.h, so move LLThread::lockData() and unlockData() to the .cpp file. Similarly, remove llrefcount.h's #include "llmutex.h" to break circularity; instead forward-declare LLMutex. It turns out that a number of source files assumed that #include "llthread.h" would get the definition for LLMutex. Sprinkle #include "llmutex.h" as needed. In the SAFE_SSL code in llcorehttp/httpcommon.cpp, there's an ssl_thread_id() callback that returns an unsigned long to the SSL library. When LLThread:: currentID() was U32, we could simply return that. But std::thread::id is very deliberately opaque, and can't be reinterpret_cast to unsigned long. Fortunately it can be hashed because std::hash is specialized with that type. 2019-01-14T20:04:44Z andreykproductengine andreykproductengine@lindenlab.com 2019-01-14T20:04:44Z urn:sha1:26fae750ba753f32f58bd56d297f2d98c5759e50 2016-12-19T21:30:19Z Nat Goodspeed nat@lindenlab.com 2016-12-19T21:30:19Z urn:sha1:40fb9d3e58fcb28778c57a835795ff4a1ef90b98 Turns out that Monty didn't intend for the int-flavored representation of HttpStatus to expand to 64 bits even when unsigned long is that wide. So change the implicit conversion operator, and its uses, to U32 instead. That produces a consistent toHex() result for both 32-bit and 64-bit builds.