On 10 October 2011 03:49, Mark Thomas <markt_at_apache.org> wrote:
> On 08/10/2011 23:47, Greg Wilkins wrote:
> > Note that I'm not that keen on allowing applications to handle the
> > upgraded connection. I'd like to see that containers are still
> > responsible for whatever protocol is upgraded to. So we need a way
> > to expose the upgrade HTTP request to the servlet together with
> > knowledge of what target protocols the container supports.
>
> Why? Isn't that unnecessarily limiting? If we allow the application to
> handle the upgraded connection that gives the application the freedom to
> work with whatever protocol they choose. Certainly, I see the container
> providing an implementation of some protocols but I don't see (right now
> anyway) a reason to enforce that all protocols are provided by the
> container.
>
Mark,
I'm not that keen for numerous reasons... none being a real killer argument,
but they add up to general opposition (at least for me).
Playing with upgraded HTTP connections is not something to be done lightly.
There is already significant angst at the IETF about websockets with Roy
Fielding being a vocal critic of the approach. In his view (as the designer
of the HTTP upgrade mechanism), the intention was purely to allow upgrades
to better versions of HTTP or TLS etc. not to arbitrary other protocols.
Websocket has already caused significant consternation about security
concerns with non HTTP application traffic being sent through HTTP
intermediaries that do not understand the upgrade.
Application containers are meant to provide a lot more than just a raw
socket for the applications, such as resource management, security, logging,
accounting and protection from attack. Allowing an upgrade to arbitrary
protocols to happen within the application and beyond the control of the
container is likely to result many vulnerabilities that are out of control
of the containers.
Writing good protocol implementations is hard. It is even harder to do so
in a scalable way. It's not something for the application developer to
undertake. It's not even something for framework developers. It would be
difficult to do well behind the current Servlet input/output streams and
will need really good async support if it is to be done in a scalable way.
Probably also needs access to lower level socket configuration (eg linger,
halfcloses, etc.) to be able to work in a general way for all protocol
possibilities. I'm not that sure there is strong support for async IO in the
servlet spec now.
If we want extensible protocols, then I'd see more scope for coming up with
an SPI below the level of the servlet API... but that would really be
treading on the toes of all the different implementations out there that
have their own style of buffering/NIO/dispatching etc. etc.
If we do allow application space protocol implementations, then we would
really need the ability for the container to override the application and
say - "don't use the app impl, as I have my own implementation."
New upgrade protocols are not that frequent. There are 3 examples that I
know of: Upgrade to TLS, Upgrade to SPDY and upgrade to WS:
Upgrade to TLS is definitely a container responsibility - we don't want to
start using an application supplied HTTP impl just because the client used
80+upgrade rather than 443
Upgrade to SPDY is again really a container responsibility as SPDY is a HTTP
replacement and we don't want to container to suddenly give up doing all
accounting, security, logging etc because the user is using chrome.
Besides it is looking like the final SPDY is going to use TLS next protocol
negotiation rather than upgrade.
Websockets is a new semantic, but not that different to HTTP that we can
say it doesn't fall under the realm of container responsibilities. It has
taken many many years to develop and has years to go before it is known if
it is a success or not. I don't expect that another example of such a
protocol is going to sneak up on us and totally surprise container
implementers.
When deploying new protocols, there needs to be a conversation between the
protocol deployer and and the managers of the network infrastructure / data
centre and any security managers. If we allow applications to deploy new
protocols, then this established relationship is going to have to be
reinvented... which will be very disruptive when we have no other examples
that need this other than websockets.
I'd much rather that this iteration that we provide a simple way to handle
the HTTP aspects of upgrades (authentication, logging, etc.) and then throw
to a container provided implementation of a well know protocol with an API
governed by an specific RFC. That should cover the websocket case really
well. If there is then demand for further use of upgrade, we can review
that at a later date.
cheers