On 23 May 2014 18:44, Shing Wai Chan <shing.wai.chan_at_oracle.com> wrote:
>
> The current plan of record is to provide "no" API for SSE in Servlet.
>
+1
SSE so far has not been widely adopted. But even if it is, it is
essentially a content type and the current servlet specification already
provides ample mechanisms for a SSE implementation to seamlessly integrate
with a servlet container. It can use ServletContainerInitializers to
discover SSE endpoint abstractions and async IO to efficiently send the SSE
content without consuming container resources.
So I think there should be standardised SSE APIs developed, just not part
of the servlet spec. The Servlet EG's involvement should be limited to
advising whatever EG does it, how best to use the existing mechanisms.
> The current plan of record does call for standardizing HTTP 2.0 server
> push in Servlet 4.0. That work may reveal more facts to sway the
> decision.
>
>
This is a good thing to include. With the jetty implementation of SPDY, we
do push below the level of the Servlet Container, but this mostly limits us
to pushing static content, which is often handed off to CDNs anyway. It
would be good to be able to push both static and dynamic content.
The rough idea that I have had (without too much deep though), is that push
could be added to the RequestDispatcher mechanism. The way push works
in HTTP/2 is that a response to a request may include notification via push
promises of simulated request to which the server will soon send the
response to. To model this in the server we could just add a push method
to the request dispatcher, so that
request.getRequestDispatcher("/some/resource").push(request,priority);
would send on the current response a push promise for "/some/resource" with
it's simulated request based on the passed request object (ie same cookies,
UA etc.).
Note that this method would not actually do the pushing, but would schedule
a new dispatch to the servlet container when the priority criteria is met
(some streams need to be pushed before others, so let's not dispatch too
many threads all at once).
Anyway, that's just a rough idea of my current thoughts. I'll have more
to say on this as we get to the point in our http2 implementation for jetty.
Actually, while discussing http2, I would like to solicit feedback from the
EG on an issue currently being discussed in the http2 WG. Currently their
draft allows unlimited size headers to be sent in a HTTP request and
actually gives them favourable transport semantics (not flow controlled,
not segmented, must be parsed in order, etc.)
My concern is that this will fuel even more growth of applications putting
large amounts of data into headers. The problem with request headers in
particular is they must be held for the entire duration of the request
handling as even after a long async wait somebody can call
request.getParameter("foo"). So unlimited headers represents an unlimited
memory commitment for the server. This is already a problem in HTTP/1.1,
but I think the favourable transport semantics of headers in http2 will
make this more of a problem. To avoid applications growing the headers
with in appropriate data, it may be better to allow them access to HTTP
trailers (which don't have to be held for the entire request handling).
Is the API for this something we could consider in the next servlet
iteration?
cheers
--
Greg Wilkins <gregw_at_intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.