large amount of contents cause blazor to disconnect

[ScottyBlazor]

when used in Blazor server

If you have a large amount of contents in the editor, very noticeable if have images that are base64 embedded strings the code causes Blazor to disconnect. error in console: Error: Connection disconnected with error 'Error: Server returned an error on close: Connection closed with an error.'.

this happens when the JavaScript calls this code dotNetRef.invokeMethodAsync('UpdateModel', editor.getContent()); as it is above the default 32K singalR limits

see this limitation here https://github.com/dotnet/aspnetcore/issues/23179

[exalate-issue-sync[bot]]

Ref: INT-2501

[jscasca]

Thanks for bringing this up! I was not aware of this limitation. We will have to break up the call into smaller chunks to avoid this issue.

I can hopefully have a PR sometime soon unless someone else wants to barge in with a code contribution :)

[net-brain]

You can set the maximum buffer size in ConfigureServices (Startup.cs): instead of services.AddServerSideBlazor(); you should use

services.AddServerSideBlazor().AddHubOptions(o =>
            {
                o.MaximumReceiveMessageSize = 10 * 1024 * 1024; // 10MB
            })

[ScottyBlazor]

Thanks for the suggestion net-brain

unfortunately this only increases the limit it does not fix the issue, if you have a document over the new size you will get the same issue again. as well as having more setup steps for anyone wanting to use this control.

I have also read in a few places it is not good practice to increase the size limit as it is a security issue one example is in this doco https://blog.stevensanderson.com/2019/09/13/blazor-inputfile/ see the "Bandwidth, latency, and security" section

specifically Also, for security reasons, we don’t want to trust the JS-side code to send us as much data as it wants. That would let misbehaving clients occupy as much .NET memory as they want. So, all the transfer operations are initiated from the .NET side, and we can be sure to make full use of the allowed memory but no more.

the best option is to break the calls in to smaller chunks as mentioned by jscasca above

[jscasca]

So I came up with #12 that allows messages to be sent over a couple of large sized chunks to avoid hitting the signalR limit.

In theory we should only need to this on one way side but I did it both ways :shrug:

Hope to have a build soon

[jscasca]

@ScottyBlazor v0.0.4 is out now and it comes with chunking for passing parameters.

[ScottyBlazor]

thankyou @jscasca its much appreciated, I will update my code and give it a try