Subject: Re: [hybi] Fwd: Proposal: require non-final websocket frames to have a minimum payload length of X bytes

From: Tobias Oberstein <[email-masked]>
Date: Thu, 20 Jun 2013 10:15:29 -0700

Yep. That's exactly what Autobahn does when using it's streaming API: complete the message by sending an empty FIN frame.

Sent from Mobile (Google Nexus 4)

Joakim Erdfelt <[email-masked]> schrieb:

an empty frame within the context of a streaming message is possible.

if you have a websocket library that supports streaming of a message, it has to make some judgement calls on when to flush the outgoing data in the form of a fragment.
The library however has no prior knowledge of the size of the message, so the flush could occur, then the user application determines it is done streaming data and simply closes that message stream, resulting in a need for a final 0 payload length FIN frame.

--
Joakim Erdfelt <[email-masked]<mailto:[email-masked]>>
webtide.com<http://www.webtide.com/>
Developer advice, services and support
from the Jetty & CometD experts
eclipse.org/jetty<http://eclipse.org/jetty/> - cometd.org<http://cometd.org/>

On Thu, Jun 20, 2013 at 8:28 AM, Zhong Yu <[email-masked]<mailto:[email-masked]>> wrote:
Not all websocket applications treat messages as atoms. If
client/server are doing streaming (within a message), we need to
support tiny frames. The requirement of min payload length will
restrict how the protocol can be used.

Empty frames are odd, and a sender should never depend on empty frames
to carry any semantics. But why would empty frames cause any trouble
for the receiver? Can't the receiver simply discard them?

Zhong Yu

On Thu, Jun 20, 2013 at 6:12 AM, William Budd <[email-masked]<mailto:[email-masked]>> wrote:
>>> This is particularly annoying when a websocket server wants to guard
>>> against denial of service attacks, because in the case of deliberately
>>> over-fragmented messages the server needs to process an excessive (or
>>
>> Guard against this kind of attack could be done by frame/sec limit,
>> fragments/message limit, idle (no new payload octet coming) timeout, etc.
>
> Yes, careful timing can certainly catch a lot of unreasonable traffic
> (albeit at the cost of a significant processing overhead in some
> cases). I'm not sure what you mean by a fragments/message limit
> though. If a server decides to drop fragments beyond a certain
> fragment count, isn't that a violation of RFC 6455 (as the reason for
> declining would be based on the framing rather than on the contents of
> the payload)?
>
>>> infinite?) amount of framing data before it has enough payload data to
>>> determine whether the message is valid with regard to any API built on
>>> top of the websocket layer.
>>
>> With this change, we can delegate DoS detection to code after defragment. I
>> agree that it's useful. For keep-alive we already have ping/pong, so nobody
>> should miss empty (non-first && non-last) frames.
>
> Glad to hear that!
>
>>> This issue could be easily prevented if websocket frames that do not
>>> have the FIN bit set need to specify a payload of at least X bytes
>>
>> I'd relax it to "!FIN && !first".
>
> Alright, but could you give an example of when it would be desirable
> to make the first frame of a fragmented message (very) small?
>
>>> (where I would vote for X to be 125, but could conceivably be as small
>>> as 8 or so bytes). Any non-FIN frames smaller than X could then simply
>>
>> If we were still standardizing per-frame mux, I'd say "this could be source
>> of head of line blocking when used for multiplexing. Though 125 sounds small
>> enough not to clog multiplexed connection, I don't want X to be greater than
>> 1".
>>
>> But now in the latest mux spec, we're encapsulating fragments into messages.
>> So, it's fine wrt current mux spec.
>
> A fortunate coincidence. :)
>
>> I don't want to get bothered by minimum transmission unit when flushing
>> data, but in practice, we're always asked to consolidate small chunks if
>> possible to reduce overhead, and we do so.
>
> Agreed. Thank you for your thoughtful input!
>
> It would be good if other people chimed in with their opinions too,
> but if it turns out there are no significant drawbacks I hope said
> minimum size can be ratified in the next version of the websocket
> protocol.
>
> Best,
> Will
> _______________________________________________
> hybi mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/hybi
_______________________________________________
hybi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/hybi

---

From: Roberto Peon <[email-masked]>
Date: Thu, 20 Jun 2013 10:45:36 -0700

That "empty" frame carries information, namely that a FIN was sent.
The presence of a zero-length frame might also indicate something, but a
zero-length *fragment* without a FIN or other metadata seems pretty stupid.
-=R

On Thu, Jun 20, 2013 at 10:15 AM, Tobias Oberstein <
[email-masked]> wrote:

>  if you have a websocket library that supports streaming of a message, it
> has to make some judgement calls on when to flush the outgoing data in the
> form of a fragment.
> The library however has no prior knowledge of the size of the message, so
> the flush could occur, then the user application determines it is done
> streaming data and simply closes that message stream, resulting in a need
> for a final 0 payload length FIN frame.
>
>  --
> Joakim Erdfelt <[email-masked]>
> webtide.com <http://www.webtide.com/>
> eclipse.org/jetty - cometd.org
>
>
> On Thu, Jun 20, 2013 at 8:28 AM, Zhong Yu <[email-masked]> wrote:
>
>> On Thu, Jun 20, 2013 at 6:12 AM, William Budd <[email-masked]> wrote:
>> > [email-masked]
>> [email-masked]
> [email-masked]