On 6 October 2011 14:08, Alex Rojkov <alex_at_caucho.com> wrote:
> I am not sure I understand why stream based API is less secure then
> buffer based. In servlet spec there are already annotations that allow
> specifying limits for file upload and web-socket API could take similar
> approach and provide an annotation that limits how much data can be
> read from a stream for a particular message. If limit is exceeded read()
> could throw a specialized IOException.
It is not less secure. It really is just a transference of
responsibility for buffering and limit enforcement to the application,
which can mean that some applications are less good at doing such
things.
Sure the container could enforce the limits, but then have the
application do all the work associated with streaming, but that is the
worst of both worlds.
> I am strongly pro-stream because a stream based API gives the programmer
> flexibility to read in chunks that are appropriate for the application or a framework
> which may be a more frequent case.
This kind of thing has been extensively discussed in the working
group. The reason that frames are not exposed to the browser API and
are not intended to be exposed on the server side is precisely because
it is NOT the intention of websockets to allow semantic meaning to be
attached to any boundary less than a message. If an application
wants to handle "chunks" of data, then they need to send each chunk as
a separate WS message.
To allow processing of partial messages will only encourage the crazy
idea of doing comet like streaming within a large websocket message.
So I think that avoiding huge buffers is a reasonable argument for
streaming APIs, but allowing semantic interpretation of partial
messages is not.
> Consider a case where you need to stream megabytes of data from a client
> to the server. This is a frequent case and it should be solvable in a manner
> that no strenuous on memory. Especially when many clients do the same.
Send the megabytes as lots of small WS messages.
regards