OK fair enough, let's try putting that in for now.
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.
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.
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
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.
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
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.
|| Danny Coward