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:
Example Hixie-75 Request (captured from Safari 5.0):
GET /chat HTTP/1.1
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
^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.