[jetty-dev] rfc6455 question (websockets)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[jetty-dev] rfc6455 question (websockets)

makc
I have a question about these lines:
 
 
rfc section 4.2.1 does say that client is expected to send "A |Sec-WebSocket-Version| header field, with a value of 13" and that "If the server, while reading the handshake, finds that the client did not send a handshake that matches the description below... the server MUST stop processing the client's handshake and return an HTTP response with an appropriate error code (such as 400 Bad Request)"
 
jetty's code above does send 400, but note that 400 is only listed as one of "appropriate error codes". Next, section 4.2.2 states this:
 
"/version/
          The |Sec-WebSocket-Version| header field in the client's
          handshake includes the version of the WebSocket Protocol with
          which the client is attempting to communicate.  If this
          version does not match a version understood by the server, the
          server MUST abort the WebSocket handshake described in this
          section and instead send an appropriate HTTP error code (such
          as 426 Upgrade Required) and a |Sec-WebSocket-Version| header
          field indicating the version(s) the server is capable of
          understanding.
"
 
so basically, jetty might reply with 426 and version = 13 instead of 400.
 
The reason I am looking into this is because I have the client here that tries to connect with version 8 and then closes the connection in response to 400. Now if jetty would return 426, the client might retry with version 13, right? I now made the client to start with 13, but decided to ask this here just in case. 


_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] rfc6455 question (websockets)

Joakim Erdfelt-9
Interesting.

Not sure Error 426 would be well supported on browsers.
But the missing Sec-WebSocket-Version on the response for error 400 is definate bug.


--
Joakim Erdfelt <[hidden email]>
Developer advice, services and support
from the Jetty & CometD experts


On Wed, Aug 7, 2013 at 3:08 PM, Makc <[hidden email]> wrote:
I have a question about these lines:
 
 
rfc section 4.2.1 does say that client is expected to send "A |Sec-WebSocket-Version| header field, with a value of 13" and that "If the server, while reading the handshake, finds that the client did not send a handshake that matches the description below... the server MUST stop processing the client's handshake and return an HTTP response with an appropriate error code (such as 400 Bad Request)"
 
jetty's code above does send 400, but note that 400 is only listed as one of "appropriate error codes". Next, section 4.2.2 states this:
 
"/version/
          The |Sec-WebSocket-Version| header field in the client's
          handshake includes the version of the WebSocket Protocol with
          which the client is attempting to communicate.  If this
          version does not match a version understood by the server, the
          server MUST abort the WebSocket handshake described in this
          section and instead send an appropriate HTTP error code (such
          as 426 Upgrade Required) and a |Sec-WebSocket-Version| header
          field indicating the version(s) the server is capable of
          understanding.
"
 
so basically, jetty might reply with 426 and version = 13 instead of 400.
 
The reason I am looking into this is because I have the client here that tries to connect with version 8 and then closes the connection in response to 400. Now if jetty would return 426, the client might retry with version 13, right? I now made the client to start with 13, but decided to ask this here just in case. 


_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev



_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] rfc6455 question (websockets)

makc
It's not missing.

_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] rfc6455 question (websockets)

Joakim Erdfelt-9
Seems that "426 Upgrade Required", from RFC 2817, is really for TLS related traffic.
Yet, oddly RFC 6455: Section 4.2.2 Sending the Server's Opening Handshake says to use it for /version/ response.

Not sure about this.
This would require some extensive testing on browsers to see how they behave.

--
Joakim Erdfelt <[hidden email]>
Developer advice, services and support
from the Jetty & CometD experts


On Wed, Aug 7, 2013 at 3:19 PM, Makc <[hidden email]> wrote:
It's not missing.

_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev



_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] rfc6455 question (websockets)

makc
I now see that it's version in response and not status code that should prompt the client to retry, any way.

_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev