jsr356-experts@websocket-spec.java.net

[jsr356-experts] Re: [jsr356-users] Re: For Review: v002 API and example code

From: Greg Wilkins <gregw_at_intalio.com>
Date: Sat, 14 Jul 2012 06:47:16 +1000

On 14 July 2012 03:57, Jeanfrancois Arcand <jfarcand.oss_at_gmail.com> wrote:
> @WebServlet(urlPatterns={"/blah"}
> class MyServlet {
> void doGet(...) {
> if ("websocket".equals(req.getHeader("Upgrade")) {
> req.upgrade(...); // websockety stuff
> } else {
> // standard GET request
> }
> }
> }

This is more or less how Jetty handles the upgrade. 2 concerns about this:

firstly we don't want to make the API dependent on some future servlet
3.1 upgrade mechanism so if we do defer upgrade handling to the
container, then it needs to be done without mandating a particular
upgrade mechanism.

But the tougher issue is MUX. If the processing of an upgrade
request is done by the normal container auth + flilters + servlet
handling, then we have to make this same path available when
processing new channels within a muxed connection. Thus a fact
request will have to be made and allowed to flow through the
container to be handled in the same way. This is somewhat ugly -
but I've not got a better idea.





-- 
Greg Wilkins <gregw_at_intalio.com>
www.webtide.com
Developer advice, services and support
from the Jetty & CometD experts.