Skip to main content

[jsr356-experts] Re: Question on Handshake / Headers

  • From: Danny Coward < >
  • To:
  • Cc: Justin Lee < >
  • Subject: [jsr356-experts] Re: Question on Handshake / Headers
  • Date: Fri, 11 May 2012 15:57:07 -0700

Thanks Justin,
" type="cite">

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.
" type="cite">
 

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.

" type="cite">
 
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.
" type="cite">
 

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
" type="cite">


-- 


--
Danny Coward
Java EE
Oracle Corporation


[jsr356-experts] Question on Handshake / Headers

Danny Coward 05/10/2012

[jsr356-experts] Re: Question on Handshake / Headers

Justin Lee 05/10/2012

[jsr356-experts] Re: Question on Handshake / Headers

Danny Coward 05/11/2012

[jsr356-experts] Re: Question on Handshake / Headers

Mark Thomas 05/10/2012

[jsr356-experts] Re: Question on Handshake / Headers

Danny Coward 05/11/2012
 
 
Close
loading
Please Confirm
Close