On Wed, May 9, 2012 at 8:13 PM, Danny Coward <danny.coward_at_oracle.com>wrote:
> Hi folks,
>
> I've been sifting through all the APIs in our project list and am working
> on a draft/for discussion API. But one thing that came up a few emails ago
> a couple of times is the issue of access to the header information in the
> handshake request.
>
> Which headers are needed in the process seem...clearish to me - the
> websocket protocol lays out headers like Origin, or Sec-WebSocket-Protocol
> for example, and how the client should use them and the server process them.
>
> If we assume that the web socket implementation 'will take care of the
> plumbing' and the application developer will take care of 'application
> specific things', its less clear to me what information in the handshake is
> plumbing and what is application specific. And so, while I think through a
> draft API, I'm thinking through what needs to be exposed through the API,
> and what is just dealt with in the implementation.
>
> So, please check my thinking !
>
> Origin header - mostly 'plumbing': client implementation may or may not
> provide, server implementation may or may not check. App developer might
> care to know if the server's policy is to check clients declared name or
> not ?
>
Might be useful to expose for CORS resolution, etc.
>
> Sec-WebSocket-Protocol - 'application specific': particular client apps
> will want to declare an ordered list of preferred subprotocols, a
> particular server app will want to respond with a single preferred
> subprotocol it will support for a given client based on its declared
> subprotocol list.
>
> Sec-WebSocket-Extensions - similar responsibilities as above, except the
> server-side applications respond with a list of extensions.
>
> (Sidebar: what extensions are people here seeing used ?)
>
>
I'm not sure it makes sense to expose the extensions to application level
negotiation. Most of the extensions I've seen so far deal with wire level
aspects like compression and the like.
> Request-URI : I expect we will have some discussion in the near future
> about mapping schemes for URIs for websocket endpoints. Until then, safe to
> say the application layer will have knowledge of the address space in some
> way.
>
I'd always hoped to get annotation based mapping into glassfish but I could
never quite find the traction. It wouldn't hurt to expose it, but like
when writing servlets the request URI almost never mattered once inside
doXXX(). Query parameters might be used here and there but it's always
struck me as kind of weird to use parameters for a websocket URL. I don't
recall offhand if the spec talks about it one way or the other.
>
> Cookies: Seems like a no-brainer to expose the HttpSession to applications
> that are deployed inside a web application, but that could be done without
> exposing all the cookies on the handshake request to the app developer. So,
> what application-specific uses of Cookies have people made, or heard of ?
> It would help to have some use cases here to know how/if to expose this to
> the developer.
>
If we expose the HttpSession during the handshake, app developers get
cookies for free really.
--
Justin Lee
http://antwerkz.com