Re: [jetty-dev] websocket-client-9.0.0.M5 does not allow to handle faile

[Florian Dummert <florian.dummert@xxxxxxxxxxxxxxx>]

Thanks for the prompt action! But I think the fix still misses one
required feature - I still can't see how to access the original HTTP
status code:

An application using the websocket-client lib needs to be able to access
the original HTTP status code. The application needs to react in
different ways according to the status. 500 is handled differently from
401 or 302.
What about simply including the HTTP status code in the UpgradeException
as an extra field? This seems to be rather non-intrusive and allows the
application to catch an ExecutionException, retrieve the
UpgradeException, access the status code and do whatever it likes. Maybe
it is not the most obvious API then, but at least, it is possible.

Best Regards,
Florian

> Thanks, I went ahead and filed it as a bug:
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=399397
> 
> --
> Joakim Erdfelt <joakim@xxxxxxxxxxx>
> webtide.com
> Developer advice, services and support
> from the Jetty & CometD experts
> eclipse.org/jetty - cometd.org
> 
> 
> On Tue, Jan 29, 2013 at 3:32 AM, Florian Dummert <florian.dummert@xxxxxxxxxxxxxxx> wrote:
> 
>     I think the API of the websocket-client-9.0.0.M5 does not allow to
>     handle failed upgrade requests as mandated by the spec.
> 
>     RFC6455 (p. 18) defines:
> 
>        Once the client's opening handshake has been sent, the client MUST
>        wait for a response from the server before sending any further data.
>        The client MUST validate the server's response as follows:
> 
>        1.  If the status code received from the server is not 101, the
>            client handles the response per HTTP [RFC2616] procedures.  In
>            particular, the client might perform authentication if it
>            receives a 401 status code; the server might redirect the client
>            using a 3xx status code (but clients are not required to follow
>            them), etc.  Otherwise, proceed as follows.
> 
>     The method ClientUpgradeResponse::validateWebSocketHash, however, only
>     checks for the presence of the Sec-WebSocket-Accept header and, if not
>     present, throws an UpgradeException. Maybe I'm missing something, but it
>     seems whenever the exception is being thrown, the original HTTP status
>     code (which was stored in the response before), is getting lost. That
>     does not allow me to handle such server errors.
>     _______________________________________________
>     jetty-dev mailing list
>     jetty-dev@xxxxxxxxxxx
>     https://dev.eclipse.org/mailman/listinfo/jetty-dev