> I agree that we need to do something for websockets this iteration of
> the servlet spec.
+1 Web developers are going to want websocket support as soon as browsers
support it. It's exiting, it's new, it solves a push/poll Ajax problem and has high
performance. I am glad to see so many people vouching for web-socket API
included in this JSR.
> By giving a streaming interface to the application, you are just going
> to make the application responsible for an extra layer of buffering
> and for policing any resource limits. Applications will often have
> no idea (or more importantly, often no care) about resource limits
> and I suspect that the vast majority of implementations would just
> stream the messages into unlimited StringBuilders. With streaming we
> would have many many applications vulnerable to simple DOS attacks.
> Also note that if limits are exceeded, then the WS connection needs to
> be closed with the correct error codes, else clients are likely to
> just try again.
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.
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.
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.
Servlet API is a simple API and it is mostly based on streams which fit the task
perfectly.
alex
>
> It is the job of the container to protect applications from these
> kinds of concerns - even if it means that we have to impose some
> limits. We already do this with HTTP, where the server imposes a
> maximum size on the URI, the headers and often on POST form content.
> Just because the HTTP protocol does not limit the size of URIs,
> headers or form content does not mean that we went to a stream API for
> getPathInfo(), getHeader(String) and getParameter(String).
>
> So I strongly believe that we should offer a simple message based API
> (byte[] and String), with limits imposed and enforced by the
> container, which will run the correct error conversations and any
> negotiations as needed.
>
>
> regards
>
>