2012-11-24 3 views
5

HTTP 연결을 websocket으로 업그레이드 할 때 선택적인 HTTP 헤더 인 'Sec-WebSocket-Protocol'에 하나 이상의 하위 프로토콜을 제공 할 수 있습니다.요청 된 websocket 하위 프로토콜이 지원/인식되지 않는 경우 HTTP 응답 코드

서버가 하위 프로토콜을 허용하는 경우 서버는 HTTP 응답 코드 101 ("HTTP/1.1 101 전환 프로토콜")로 응답하고 선택한 하위 프로토콜을 나타내는 HTTP 헤더 'Sec-WebSocket-Protocol'을 포함합니다.

그러나 서버가 알려지지 않은/지원되지 않는 서브 프로토콜을 올바르게 처리하는 방법은 무엇입니까?

일부 HTTP 응답 코드를 사용하여 HTTP 연결 '내부에서'수행해야합니까?

또는 연결을 websocket으로 업그레이드해야하며 미리 정의 된 웹 소켓 상태 코드 중 일부와 함께 '프레임 닫기'를 보내서 서버가 즉시 닫을 수 있습니까?

RFC6455는 무엇을 말합니까? 나는 결론에 도달 할 수 없다. 기존 서버 구현은 어떻게 처리합니까?

안부 /당/RFC 6455에서 간단한 엿볼에서

+0

4.2.2 절에서 이에 대한 정보가 있습니다 : "서버가 제안 된 서브 프로토콜 중 하나 (...)에 동의하지 않으려 고하지만 연결에 어떤 일이 발생했는지 완전히 알 수는 없습니다 . – pimvdb

답변

4

, 나는 웹 소켓 서브 프로토콜은 선택과 협상을 믿습니다. "서버 Rquirements"구역에 4.2.2에서 :

/subprotocol/ 
     Either a single value representing the subprotocol the server 
     is ready to use or null. The value chosen MUST be derived 
     from the client's handshake, specifically by selecting one of 
     the values from the |Sec-WebSocket-Protocol| field that the 
     server is willing to use for this connection (if any). If the 
     client's handshake did not contain such a header field or if 
     the server does not agree to any of the client's requested 
     subprotocols, the only acceptable value is null. The absence 
     of such a field is equivalent to the null value (meaning that 
     if the server does not wish to agree to one of the suggested 
     subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol| 
     header field in its response). The empty string is not the 
     same as the null value for these purposes and is not a legal 
     value for this field. The ABNF for the value of this header 
     field is (token), where the definitions of constructs and 
     rules are as given in [RFC2616]. 

는 서버는 클라이언트와 서브 프로토콜을 사용하도록 동의하지 않은 경우 '널 (null)'이외의 값으로 하위 프로토콜 응답 헤더를 보내지해야하고, 그것은이다 그 시점에서 연결을 계속하거나 종료하는 책임은 고객에게 있습니다.

+0

비록 대부분의 경우 서브 프로토콜에 대한 지원이 부족하면 websocket으로 연결을 업그레이드하는 데 별 도움이되지 않을 것이라고 생각합니다. 서버가 요청 된 서브 프로토콜을 제공하지 않는다는 것을 나타내는 연결을 설정하면 클라이언트 측에서이를 로그/처리 할 수 ​​있습니다. – PerS

+0

RFC의 요점은 서브 프로토콜이 SSL 핸드 셰이크 프로세스의 암호 교환과 같은 협상 된 확장이라는 것입니다.이것이 클라이언트 측에서 종료되어야하는 이유입니다 : 클라이언트와 서버가 공통 서브 프로토콜을 지원할 수없는 경우, 서버는 다른 가능성을 위해 연결을 열어두기를 원하지만 분명히 통신 할 수 없습니다. – jmkeyes

+0

예.이 말이 맞습니다. 브라우저 용 [javascript Websocket API] (http://www.w3.org/TR/websockets/)를 살펴본 후 몇 가지 간단한 테스트를 수행했습니다. 연결이 설정 될 때 설정된 읽기 전용 '프로토콜'매개 변수를 사용하면 클라이언트가 지원되지 않는 서브 프로토콜 상황을 처리 할 수 ​​있습니다. – PerS

0

WebSocket의 전체적인 요점은 WebSocket을 사용하여 클라이언트에서 서버로 특정 프로토콜을 실행하는 것입니다. 그러나 클라이언트와 서버는 양쪽 끝이 들어오는 WS 메시지로 무엇을해야하는지 알 수 있도록 프로토콜을 알아야합니다. WS 메시지 처리는 TCP 수준에서 수행하는 것과 다르지 않습니다. 프로토콜 필드를 사용할 필요가 없으며 호환성을 강화하려는 경우에만 관련이 있습니다.

Kaazing 서버의 경우 기본 websocket 레이어 위에 위치 할 특정 프로토콜 라이브러리를 제공합니다. Github에서 다양한 프로토콜 라이브러리를 찾을 수도 있습니다. 핸드 셰이크를 제외하고는 다른 모든 것이 TCP로 처리하는 방법입니다. websocket 메시지를 처리하고 프로토콜 디코딩을 시도합니다. 핸드 셰이크의 프로토콜 필드는 라이브러리가 실제로 일치하는 프로토콜 라이브러리인지 확인하는 데 사용해야합니다. 예를 들어 서버가 STOMP를 말하고 클라이언트와 연결하려고 시도하고 STOMP을 말하고 싶다면 STOMP 라이브러리가 프로토콜 필드를 확인하여 일치하는지 확인해야합니다. 엔드 포인트는 예를 들어 AMQP 0.9 및 AMQP 1.0을 말할 수있는 우선 순위를 나타낼 수 있으며, 둘 다 사용할 수있는 경우 AMQP 1.0을 선택합니다. 엔드 포인트 중 하나가 다른 엔드가 말할 수있는 프로토콜을 사용하지 않으면 널을 리턴 할 수 있으므로 연결이 종료됩니다.