How is the
ServerEndpointConfig.Configurator.getNegotiatedExtensions(List<Extension>
installed, List<Extension> requested) supposed to work?
There is really no way to delegate this negotiation step to an end-user
class.
This is something that has to occur on the server implementation itself.
Rationale:
The server knows what extensions are installed.
The client requests a certain set of extensions.
The server has to negotiate what extensions it can use based on what is
installed and what is requested. This requires that each extension also
negotiate any parameters for that extension as well.
So for example, a server with permessage-deflate extension installed.
The client can request
Sec-WebSocket-Extensions: permessage-deflate; c2s_max_window_bits;
s2c_max_window_bits=10, permessage-deflate; c2s_max_window_bits
But the server will need to interrogate the actual permessage-deflate
extension implementation to know which of the 2 extension configurations
requested are supported.
In the case of Jetty, the first extension is unsupported (as its
problematic to specify max_window_bits with java) and the second extension
is the supported one.
There is also some logic needed to cull duplicate extensions that only the
server and the various extension implementation can possibly know.
Jetty will need to respond with Sec-WebSocket-Extensions:
permessage-deflate; c2s_max_window_bits to indicate that the second one is
supported, not the first.
I propose that
ServerEndpointConfig.Configurator.getNegotiatedExtensions(List<Extension>
installed, List<Extension> requested) be removed.
Another extension scenario is where there are extensions that conflict with
each other when it comes to RSV bit use, this information is not exposed by
the existing javax.websocket.Extension interface and any developer
negotiation will need to interrogate that the chosen set of extensions do
not conflict in their RSV bit use. (example: extension-foo uses RSV2 and
extension-bar also uses RSV2. Both are allowed to be installed, but only 1
of them can be used. the first one that successfully negotiates is used,
the second one will not negotiate and be be left out of the response from
the server)
Note that ServerEndpointConfig.getExtensions() will return the as
negotiated list of extensions anyway, so we are not losing this information.
If the purpose of the method is to allow the developer to control what
extensions they wish to support on the endpoint, then this needs to be
handled differently. Maybe in the future revision of this standard where
we add full Extension support.
--
Joakim Erdfelt <joakim_at_intalio.com>
webtide.com <http://www.webtide.com/>
Developer advice, services and support
from the Jetty & CometD experts
eclipse.org/jetty - cometd.org