[jsr356-experts] Re: Question on Handshake / Headers
- From: Mark Thomas <
- Subject: [jsr356-experts] Re: Question on Handshake / Headers
- Date: Thu, 10 May 2012 09:23:19 +0100
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.
> 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.
> 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.)
> 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).