Endless loading with large embedded img src="data:image/png;base64 in body

Is this a CKEditor 5 library issue ("upstream") or a Drupal issue?

This sounds site (content) specific

User pastes into CKEditor5 ... so it is a default thing to save content in Drupal.
I have not found any documentation on NOT to save base64 images... so why site specific?
If Drupal never finishes delivering a page ... it has something to do with Drupal.

Unless you help me find out what else I need to provide to classify this - it's a bug to me.
There is no error in the log.

But look at cases like this: https://www.drupal.org/project/drupal/issues/3419024 🐛 Incorrect content-length header breaks HTTP/2 with net::err_http2_protocol_error Active

@maxilein Are you implying this bug report is a duplicate?

Maybe a suspected duplicate. I lack the tools and knowledge to find out what it could be. That's why I created the case.
I can't say if it is a CKEditor5, Drupal core or other issue.

But if the node never stops loading. Which is indicated both by calling the node in the browser and by a search_api_solr error which says that SOLR did not receive the correct size information and reported premature EOF) then I figure it is a bug because two very different technologies (brwoser and SOLR server) have similar issues.

If you press on stop loading in the browser the node edit form has all the data (also the base64 code). If you delete that base64 code everything is normal. It is absolutely reproducible.

Same issue is with me. Page never stops loading then end up with the error Error code: SIGILL. Node edit page not loading properly so not even I can remove the base64 image.

I've come across this before too. The solution of course is to not use base64 images in content but there are probably things Drupal could do to avoid this, such as blocking this in CKE. That wouldn't stop people adding these in a plain textarea, but that does seem less likely. Perhaps there is a way Drupal can detect these when the content is rendered and handle it gracefully. We probably need steps to reproduce.

It's old content from beginning of D10 time. We never wanted base64 embedded in the first place.
But still there is a problem.

I could stop loading the page. And edit the source in CKEditor5 to remove the base64 stuff.