Thanks Justin,
>
>
> 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.
OK fair enough, let's try putting that in for now.
>
>
> 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.
I'm on the fence, and I see Mark has another perspective. I've just
posted a version of the API that doesn't include this.
> 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.
I haven't seen examples of people using more than just basic URLs. No
path or query parameters. As far as I can see the spec doesn't define
any semantics around it.
>
>
> 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.
OK.
- Danny
>
>
> --
> Justin Lee
> http://antwerkz.com <http://antwerkz.com/>
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation