[Bug] Data URLs exceed length limits

[Explosion-Scratch]

See: https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers
This leads to 404 errors in the network panel because of invalid URLs.

[snshn]

Hey there! That's interesting. I don't think the network panel errors is a huge problem, as long as the assets load. Do they appear to be missing/broken in the saved HTML file, when the browser renders the page?

[Explosion-Scratch]

@snshn Yes, they don't load. This is then reflected in the Network panel - The CSS file in question was several megabytes and so the data URL didn't work. The page then looked weird because it didn't have the CSS

[snshn]

Uh-oh, that's a real boo-boo. Thank you for letting me know. I've done some research prior on minimizing image size, I believe that could help. What browser was it in, if I may ask?

[Explosion-Scratch]

@snshn Modern chrome 😅 (120 I think). You can embed the string in JavaScript then create a blob URL though if it's too long, e.g:
img.src = new URL.createObjectURL(new Blob([data here])), then the blob url would be very short, that does mess things up though with the initial load.

For CSS and JS you could turn <link rel="stylesheet" href="https://example.com/style.css"> to <style>[embedded css here]</style> and likewise for script[src] to <script> (be careful with attributes like defer though)

[snshn]

Ideally JS should be unobtrusive, many people disable it by default (e.g. NoScript extension), and modifying the original document way too much could cause other problems (aside from blowing up the code base of Monolith), but you're suggesting very good solutions, thank you. I'll look into MHTML more, it could be a good format for solving these types of issues, but I agree that it's a big problem, I'm honestly a bit shocked there's a limit on the length in the browser, I assumed it's something like file size — as long as the machine has enough memory, it should work.

[Explosion-Scratch]

@snshn Your project seems a lot like SingleFile, you could see how they do it

[snshn]

If it's been solved in SingleFile, it's likely done the way you've described it — using JS to build blobs and unwrapping assets, embedding them into the HTML. I rather stay away from relying on JS, but if there's no better alternative, that approach is better than nothing. It still looks like a browser issue more than the tool's issue, as there's no length limit in the spec, that's just something browsers impose. I will eventually make Monolith reduce file size of embedded assets by not using base64 when not necessary, that's upcoming in future versions. I'll see how MHTML behaves and what could be done with large files (e.g. splitting one .js file into multiple consequently-included .js files, doing the same with .css assets). There's always a way.

[Explosion-Scratch]

@snshn For all styles and scripts you can simply inline them using script and style tags instead of link/script[src]. This should solve the issue most of the time, for images you could:

1. compress them (convert to avif/webp, etc)
2. just inline them anyways and hope it works out (browser have different limits)
3. pick 1 or 2 then use JS on page load providing at least an ok solution for people without JS.

[einarpersson]

I think I stumbled upon this today, where images worked in Firefox but not in Chrome. I see that https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/url_display_guidelines/url_display_guidelines.md#url-length

In general, the web platform does not have limits on the length of URLs (although 2^31 is a common limit). Chrome limits URLs to a maximum length of 2MB for practical reasons and to avoid causing denial-of-service problems in inter-process communication.

Pre-compressing to webp and lowering quality seems to have fixed the error. However, it would be nice if either monolith did this work for me, or at least warned me about this. The latter should be fairly quick and would help spot issues!