Remote connections
StealWonders opened this issue · 6 comments
Hello your mod (periodically) sends out remote connections.
- This isn't communicated anywhere to the user.
- Is there a way to disable this? This should be disabled by default. Is there a privacy policy for the remote endpoint? What data is sent and received etc?
- If the connection fails the entire client lags.
java.io.IOException: Server returned HTTP response code: 522 for URL: https://skins.trsha.re/25eed24a-0d2f-4902-bb79-1e43b59ddfe6.gif
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1997) ~[?:?]
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589) ~[?:?]
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:224) ~[?:?]
at dev.tr7zw.entityculling.donor.DonorSkinProvider$1.run(DonorSkinProvider.java:100) ~[entityculling-fabric-1.5.2-mc1.19.3.jar:?]
at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1395) ~[?:?]
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) ~[?:?]
at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) ~[?:?]
at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) ~[?:?]
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) ~[?:?]
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) ~[?:?]
[20:11:51] [Worker-Main-16/ERROR]: Error while loading the animated skin.
java.io.IOException: Server returned HTTP response code: 522 for URL: https://skins.trsha.re/25eed24a-0d2f-4902-bb79-1e43b59ddfe6.gif
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1997) ~[?:?]
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589) ~[?:?]
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:224) ~[?:?]
at dev.tr7zw.entityculling.donor.DonorSkinProvider$1.run(DonorSkinProvider.java:100) ~[entityculling-fabric-1.5.2-mc1.19.3.jar:?]
at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1395) ~[?:?]
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) ~[?:?]
at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) ~[?:?]
at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) ~[?:?]
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) ~[?:?]
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) ~[?:?]```
Cheers!
It's in the tr7zwDonorSettings.json config file. It should just work like optifine capes but with animated skins, for some reason, my server or cloudflare is not having a good time. The endpoint is open source: https://github.com/tr7zw/ModSkinServer , basically just serves .gif files. Nothing gets logged/processed, and sent is just the uuid of the skin that it's trying to load. The remote clientside code is here: https://github.com/tr7zw/ModComposeTemplate/blob/1.19.3/UtilityCode/src/main/java/dev/tr7zw/donor/DonorSkinProvider.java#L98 , honestly not sure why it would cause a lag, since it all should happen in the background.
I will rework it in the future, either remove it since nearly no one uses it(to be fair, never really advertised this feature), or redo the entire thing. The current version has other issues like .gif files not supporting transparency, which I wasn't aware of before, at the same time I would make it more visible/clearer to the user.
But actually, a good idea to look into how I can redirect the DNS/Cloudflare into some 404 sink. My server has not been happy about getting this many requests, even with Cloudflare caching some.
For now changed it, so that all requests get rewritten to https://skins.trsha.re/404, in the hopes that Cloudlare is smart enough to pick up that it's all the same URL, and just spits out the cached 404 page.
Update; The host now should more reliably just answer 404 😅. Changed the host in Nginx proxy manager to be just a 404 one, and did the URL rewrite so cloudflare should cache that better. Going to close the issue, since the 522 issue should ™️ no longer happen(assuming my server doesn't die and can't serve the 404).