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 <[email protected]> webtide.com <http://www.webtide.com/> - intalio.com/jetty Expert advice, services and support from from the Jetty & CometD experts eclipse.org/jetty - cometd.org On Tue, Oct 8, 2013 at 12:20 AM, Daniel Wu <[email protected]> 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 <http://www.sparrowmailapp.com/?sig> > > > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users > >
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
