jsr356-experts@websocket-spec.java.net

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

From: Danny Coward <danny.coward_at_oracle.com>
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:
> 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.
>
>> 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.
> +1
>
>> Sec-WebSocket-Extensions - similar responsibilities as above, except the
>> server-side applications respond with a list of extensions.
> +1
>
>> (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.

>
>> 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.
>
>> 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.

Cheers,

- Danny
>
> Mark


-- 
<http://www.oracle.com> 	*Danny Coward *
Java EE
Oracle Corporation