Skip to content

Report figures in max payload size exceeded error#1816

Closed
nraynaud wants to merge 1 commit intowebsockets:masterfrom
nraynaud:patch-1
Closed

Report figures in max payload size exceeded error#1816
nraynaud wants to merge 1 commit intowebsockets:masterfrom
nraynaud:patch-1

Conversation

@nraynaud
Copy link
Copy Markdown

@nraynaud nraynaud commented Nov 8, 2020

No description provided.

@lpinca
Copy link
Copy Markdown
Member

lpinca commented Nov 8, 2020

The maximum allowed message size is set with the maxPayload option and defaults to 100 MiB so it is already known. I don't want it to be present in the error message, it's redundant.

The error can also be raised on a chunk of decompressed data and at that point the message size is not known. Something similar also applies to fragmented messages. The error can be raised before knowing the size of the full message.

Also, what is the advantage of printing the size of the message that exceeded the threshold in the error message?

@nraynaud
Copy link
Copy Markdown
Author

nraynaud commented Nov 8, 2020

I just had this error happen to me, I had never used websocket myself, never looked into it, there is a ton of code between what I was doing and the actual socket, written by my co-workers before I even joined the company. (it's like 3 dependencies down in NPM)

Looking all this up was a bit of a pain, and knowing how much I am over the limit is helpful to react: if I'm twice over the limit then I can optimize, but if I'm 100 times the limit, I'll need to do something more drastic, and measuring the size of my message is a bit of a pain because I'm quite far from websocket.

I'd still advise you to write as much as you know about the error because it will be helpful in a lot of cases, for the other ones, we'll just dig, like I had to do today.

@lpinca
Copy link
Copy Markdown
Member

lpinca commented Nov 8, 2020

if I'm twice over the limit then I can optimize, but if I'm 100 times the limit, I'll need to do something more drastic

It does not help if you have no control over the received messages and if you control them the problem does not exist because you already know the limit or you can disable it.

I'd still advise you to write as much as you know about the error because it will be helpful in a lot of cases

Yes but in this case it creates more problems than it solves due to the reasons written above.

@nraynaud
Copy link
Copy Markdown
Author

nraynaud commented Nov 8, 2020

  1. let it be clear that I create the messages, and I didn't even know there was a limit or they were JSON+gipped or anything, I never had a problem before.

  2. I don't see how it creates a problem? it's just that in some cases you don't know the full size, you can just change the wording to say that "we are already at such size", and not imply that you know the full size. And it still works when we know the full size, and still as helpful as you could be otherwise.

@lpinca
Copy link
Copy Markdown
Member

lpinca commented Nov 8, 2020

I don't see how it creates a problem? it's just that in some cases you don't know the full size, you can just change the wording to say that "we are already at such size", and not imply that you know the full size.

I really fails to understand how something like "we are already at xxx size" is a helpful message. What do I do with that?

@lpinca
Copy link
Copy Markdown
Member

lpinca commented Nov 8, 2020

The point is that the error is raised on the receiving end where "I" set a limit on the message size. "I" don't care about how much bytes have been buffered or the original full message size when the error is raised. It's up to the other peer to respect the limit.

Sorry but I don't think this is an improvement, I don't want to create an error message that is inconsistent and potentially even more confusing than it is now.

@lpinca lpinca closed this Nov 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants