Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] iOS 5.1 devices do not work with jetty websocket
What?

Version 17 is invalid for websocket.
The finalized websocket spec version is 13 (from RFC-6455)

Unfortunately, Hixie-75 is a unique beast, in so far that is breaks HTTP entirely during its request step.
With Jetty 7 and Jetty 8 we had to put in extra hacks to our HttpParser to allow for the broken HTTP requests that Safari sends it.

We even have a tests for it:
https://github.com/eclipse/jetty.project/blob/jetty-7/jetty-websocket/src/test/java/org/eclipse/jetty/websocket/helper/SafariD00.java#L89-L108

Example Hixie-75 Request (captured from Safari 5.0):

        GET /chat HTTP/1.1
        Host: machine.com
        Connection: Upgrade
        Sec-WebSocket-Key2: 12998 5 Y3 1  .P00
        Sec-WebSocket-Protocol: chat
        Upgrade: WebSocket
        Sec-WebSocket-Key1: 4 @1  46546xW%0l 1 5
        Origin: http://machine.com

        ^n:ds[4U

As you can see there are a few problems, from an HTTP point of view.
The Sec-WebSocket-Key1 and Sec-WebSocket-Key2 are random bytes, and Safari 5.x sends random bytes (even \r and \n!)
When \r and \n are sent that ends the header, making the next line invalid. (HACK required to get around this)
You also see some random bytes after the header (known as hixieBytes), but the header itself has no Content-Length specified. (HACK required to get around this)
You also see that this is a GET request, but it has content after the header. (HACK required to get around this too)
You might wonder why these are in the spec, if they break HTTP?
Well, it was intentional!  With the goal of breaking intermediaries who might be listening in on the conversation and trying to do something dumb (like caching a websocket conversation).

Fortunately, later revisions of the websocket spec fixed all of these HTTP breaking features of the spec, while still retaining the intermediary goals.

OK, Back to Jetty 7/8 ...

Both Jetty 7 and Jetty 8 support Hixie-75 up through RFC-6455, but know that all versions before RFC-6455 are considered experimental.

      We STRONGLY encourage you to NOT run the experimental websocket drafts in production!

In fact, we are considering removing all of the experimental draft versions of websocket from Jetty 7 and Jetty 8, leaving only RFC-6455.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=418140


--
Joakim Erdfelt <joakim@xxxxxxxxxxx>
Expert advice, services and support from from the Jetty & CometD experts


On Tue, Oct 8, 2013 at 12:20 AM, Daniel Wu <daniel.y.woo@xxxxxxxxx> wrote:
Hi guys,

I have a web application based on web socket, for old iOS 5.1 devices it only supports hixie75, they do not submit version or draft info in the header. However, the WebSocketServerFactory needs this kind of information to handshake, see the code below from WebSocketServerFactory:


        int version = request.getHeaderInt("Sec-WebSocket-Version");
        if (version < 0)
        {
            // Old pre-RFC version specifications (header not present in RFC-6455)
            version = request.getHeaderInt("Sec-WebSocket-Draft");
        }

        WebSocketHandshake handshaker = handshakes.get(version);
        if (handshaker == null)
        {
            LOG.warn("Unsupported Websocket version: " + version);
            // Per RFC 6455 - 4.4 - Supporting Multiple Versions of WebSocket Protocol
            // Using the examples as outlined
            response.setHeader("Sec-WebSocket-Version",supportedVersions);
            response.sendError(HttpStatus.BAD_REQUEST_400,"Unsupported websocket version specification");
            return false;
        }

My question is, is it possible to configure a fallback default Sec-WebSocket-Version? In my case, I want it to be 17 as a default value.

-- 
Daniel Wu
Sent with Sparrow


_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users


Back to the top