search

vti / protocol-websocket

Protocol::WebSocket
Other
40 stars 27 forks source link

Frame max_payload_size and fragmentation #46

Open ralesk opened 7 years ago

ralesk commented 7 years ago

Not sure if this is a bug or a truly intended behaviour, but I was really surprised to find that when P:W:Frame runs into the payload limit, it does not attempt to make multiple fragments but just dies. There also doesn't seem to be an obvious way to ask P:W:Frame to create a handful of frames that are continuations of each other (preferably with the payload per frame limited to a certain size). Supposedly, next_bytes does things to the fragments array, but I only ever seem to get "" out of it.

vti commented 7 years ago

Fragments are too low level for the user to know about them. Imagine you received a JSON message in fragments, you don't want user to deal with fragments, next_bytes should return the data that is parsed later by the user. Don't you think so?

ralesk commented 7 years ago

Ah, meanwhile I realised that next_bytes is for parsing and that is indeed documented, so never mind that bit. (Also updated the original comment in that I was looking at it wrong and it was really an empty string, not \x00)

I wonder then what the use is of the max_payload_size instruction for frame generation. Other than it croaking if we bump into it anyway.

vti commented 7 years ago

max_payload_size is smth like a safe measure, you can switch it off completely just by passing undef or 0 as a value. Maybe it's a bit strange, but that doesn't hurt and you can switch it off easily. Does this make sense?

vti commented 7 years ago

I think I implemented it because one of the WebSocket RFCs suggested controlling the payload size on the software level. Not that sure though... :)

ralesk commented 7 years ago

Okay, it makes sense this way, thanks :) I got around it by implementing my own fragmentation routine, should hopefully do what it has to.