userstyles.world
userstyles.world copied to clipboard
userstyles-world
Error: "413 Request Entity Too Large" when i want change the screenshot
That's with a similar screenshot (size <200 kb) i can't replace the old one.
I use Waterfox Classic
@vednoc 413 errors is IIRC handled by Nginx.
The default client_max_body_size is set to 1MB. There's two ways to fix this issue:
- Increase the size to 2MB or more;
- Split metadata and code into two forms. This will also fix the issue with "updated at" dates (Discord message).
@decembre I apologize for late reply. Resolving this issue in the preferred way will take some time, so I took the shortcut and increased client_max_body_size to 4MB. It should be plenty now. 😊
Haa.. sorry. I wanted to test the same thing and now.... I always can't change the preview screenshot: Error: "413 Request Entity Too Large" :-(
I'm still getting this error as well.
You're asking users to post a website screenshot. What did you expect? Of course these pictures can be quite large: I just made one that turns out as 15MB. Just using Firefox' built-in screenshotting tool - so there's nothing I can reasonably/quickly do about that - I don't want to dive into some program to make my screenshot look worse.
You're asking users to post a website screenshot. What did you expect?
I'd expect a simple 1080x1920 screenshot of some site, which within all photo compressions/formats can be done under 4mb.
Of course these pictures can be quite large: I just made one that turns out as 15MB. Just using Firefox' built-in screenshotting tool -
15MB is quite large for a simple screenshot, it just sounds like a bug to me in my ears.
The limit for 4Mb is also set because we want to send small screenshots to the user, so they won't suck up their entire bandwidth if someone is having a large screenshot.
[...] it just sounds like a bug to me in my ears.
It's not a bug. This happens when you have an "expensive" image (in terms of individual colors) that gets heavier when paired with high resolution. In the case of @thany's userstyle, the image is 3806x1956px, and it can be considered one of the worst-case scenarios, so no wonder it's 15MB. Take HD, FullHD and 4K screenshots of this and this image if you want to see the difference.
The limit for 4Mb is also set because we want to send small screenshots to the user [...]
It's actually 8MB. I increased it just enough so that expensive FullHD images can go through without issues. This is still a lot more than 200KB on USo, which will be good for well over 80% of our users (from what I can tell, it's slightly above 99%).
[...] so they won't suck up their entire bandwidth if someone is having a large screenshot.
That, but it also protects us from dealing with someone's dump of /dev/urandom that's disguised as an image.
[...] it just sounds like a bug to me in my ears.
It's not a bug. This happens when you have an "expensive" image (in terms of individual colors) that gets heavier when paired with high resolution. In the case of @thany's userstyle, the image is 3806x1956px, and it can be considered one of the worst-case scenarios, so no wonder it's 15MB. Take HD, FullHD and 4K screenshots of this and this image if you want to see the difference.
No offense, but a 4K screen (and resulting screenshot) is nothing out of the ordinary these days. Using that as the "reason" for problems, is really starting to feel like a weak excuse in 2021. You're not the only one, but it does need to be said. 4K is normal in 2021, and a FHD screenshot looks blurry to me. Wouldn't I want my screenshot to look good? Of course I would 😉
I had no choice other than to make it lossy, which is terrible for website screenshots. Sure, It happens to contain a photograph. But I also just installed a 66GB game, so what's 15MB these days? If you want to serve lower-res images to lower-res screen, go ahead, but it makes sense that the uploaded material is the best available quality, so that it won't show exaggarated artefacts when autoscaling for other screen formats. This is why proper cameras also produce lossless pictures, not jpeg.
a more complicated solution would be automatically scaling large screenshots for smaller devices + using more efficient formats like webp and avif when the client supports it. Certainly 4k screenshots should be supported.
Also some js to lossily compress complex images before sending could be helpful - perhaps the client could even take over the responsibility of converting between sizes and formats for the server (or at least send over an avif instead of a png)
No offense, but a 4K screen (and resulting screenshot) is nothing out of the ordinary these days. Using that as the "reason" for problems, is really starting to feel like a weak excuse in 2021. You're not the only one, but it does need to be said. 4K is normal in 2021, and a FHD screenshot looks blurry to me. Wouldn't I want my screenshot to look good? Of course I would wink
I'm not sure if the question "Is 4K is a normal screen size" was in this issue/discussion. If it was - 4K is perfectly a fine resolution and normal these days. While the screenshot will look fine on your screen and on any smaller screen it will look fine*, also the screenshot will never take in your full screen as it will be at it large take in 2/3 of the screen size. It's rather the size of the resulting screenshot that is the problem.
I had no choice other than to make it lossy, which is terrible for website screenshots.
It's less noticeable for website screenshots than for a lot of other types of content within my own experience, lossy compressions will mostly be notice-able around text and photographic elements, but the main layout of sites and colors are still intact with most lossy compressions.
But I also just installed a 66GB game, so what's 15MB these days?
It's a lot for the web, well it might be not a lot for you or for me. A lot of people around the globe don't have great internet connection, let alone have a stable 5Mb/s download speed. Because download speeds aren't great for everyone is one of the primary targets that compression exists. So what is 15Mb these days? For you and me not a lot, but for a lot of people it can be a reason to not check your style because showing the image takes too long.
If you want to serve lower-res images to lower-res screen, go ahead, but it makes sense that the uploaded material is the best available quality, so that it won't show exaggarated artefacts when autoscaling for other screen formats.
In that sense I should be uploading my screenshots in bitmaps for the best quality ;). Down-scaling and better formats can only do so much, it will always be affected by the initial size of the screenshot to keep much of the information in it.
This is why proper cameras also produce lossless pictures, not jpeg.
Yet, you wouldn't mind waiting a few seconds to wait before the pictures are transferred to your computer, while users will browse to the next style if the image hasn't loaded within a few seconds[1].
a more complicated solution would be automatically scaling large screenshots for smaller devices + using more efficient formats like webp and avif when the client supports it. Certainly 4k screenshots should be supported.
We are currently converting to webp, but even that will result at best in ~20% size reduction without suffering too much compression artifacts. Using avif is a no-go as current libraries are very multi-threaded and time-consuming for converting avif which already had resulted in lock-ups from the USw server.
Also some js to lossily compress complex images before sending could be helpful - perhaps the client could even take over the responsibility of converting between sizes and formats for the server (or at least send over an avif instead of a png)
That would be interesting, but we currently also store the original image as we sometimes tweak the parameters of the compression and formats a bit to have better size reductions etc. And thus all the images needs to be re-converted, so we will need the original image either way.
- https://web.dev/why-speed-matters/
Regards, Gusted