Skip to main content

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

  • From: Danny Coward < >
  • To:
  • Cc: Mark Thomas < >
  • Subject: [jsr356-experts] Re: Question on Handshake / Headers
  • Date: Fri, 11 May 2012 16:07:09 -0700

Hi Mark - thanks for the comments. See below:
On 5/10/12 1:23 AM, Mark Thomas wrote:
" type="cite">
On 10/05/2012 01:13, Danny Coward wrote:
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 ?
I view this as a per endpoint decision, not a server wide one. By
default the server accepts everything and it is up to the endpoint to be
more selective if it wishes.
OK, I've added this into the initial discussion for now. I'm hoping that containers will provide their own mechanisms for verifying Origin headers and not leave it all up to developers ! Perhaps we require containers to support the verification and allow developers to configure it, I'm not sure.
" 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 ?)
Nothing yet, but it is early days for the Tomcat WebSocket implementation.
I have left this out of the API for now, because I'm not sure yet.

" 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.
On the configuration side, certainly. At runtime? Not so sure.

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.
None as yet. This raises an interesting question. The concept of an HTTP
session exists because HTTP is stateless and a mechanism was required to
maintain state. WebSocket is stateful. Therefore, why would an
additional mechanism be required for maintaining state? That said, I can
see a requirement for the web application and web socket connection to
pass information (state) between them. This could be via the HTTP
session but is that the best way? (I don't have an answer to that.)
I hadn't seen exposing the HttpSession as a means to maintain the state of the web socket connection. More that most web socket clients appear to be _javascript_ apps in a web application. So, the developer of the server piece of those web socket apps is likely to be interested in what else is going on in the rest of web application - like who the authenticated user of the web application is, or the shopping cart, or any other global state associated with the user of the application. Or maybe even as a way to share information between web socket endpoints that are part of the same web application.
" type="cite">

Any other Request headers that either specific client applications or
specific server applications are making use of that you know ?
Nothing as yet but we did have a general discussion about applications
perhaps wanting access to the request during the upgrade process and
came to the conclusion that providing a read-only copy of the HTTP
headers would be sufficient although we held off implementing it until
someone asked for it (they haven't yet).
OK. Well, its always a safe bet to hand them everything in case they need it all :) But I'd like to build a list of what they might need before we expose everything - so do keep us posted if specific use cases come up.


- 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
Please Confirm