Hi (again) :)
reponse to OPTIONS is not defined; Tyrus does not handle it, so it
passes back to container and if there is no other filter which would
want to respond, 404 is returned.
I don't see an issue (as Tyrus developer), but I agree there could be
something useful returned (wsadl? :). I think we should NOT produce
something standard, like list of allowed http methods, simply because
there is another requirement - upgrade header have to be present. Do you
have any suggestion about what we could return? I was thinking about
something 'like' wadl, but don't want to create "just another
proprietary descriptor". Another solution might be having standard rest
resource somewhere and feed it with data from Tyrus..
Another problem might be with definition of what should be shared - list
of URIs/path templates? We could add some info about message handlers,
but only for annotated endpoints, since programmatic ones are created
when onOpen is called..
Pavel
On 5/15/13 2:53 PM, Gerard Davison wrote:
> Hi,
>
> So I was playing about with a simple Web Socket endpoint deployed to a a local Grizzyly container using the following code:
>
> Server server = new Server("localhost", 8025, "/", EchoBean.class);
> server.start();
>
> As an experiment I tried to do an OPTIONS request on the http://localhost:8025/echo but I got 404 returned, I am not sure what I was expecting but not that.
>
> What would be a reasonable response? The reason I am asking is that it would be really nice if client tooling could ask a question and be able to identify a Web Socket resource without trying to connect. I am not aware of a header pair such as TE/transfer-encoding for Upgrade perhaps I am just missing it in the RFC.
>
> Thanks,
>
> Gerard
>