Subject: [hybi] Indicating acceptable protocols in a 426 Upgrade Required Status response

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Thu, 7 Apr 2011 17:59:27 +0000

The latest HTTP/1.1-bis draft [1] includes a definition of the "426 Upgrade Required" status code which was adopted from RFC 2817. This allows a server to send back a response indicating that an upgrade protocol such as WebSocket is required:

     HTTP/1.1 426 Upgrade Required

     Upgrade: websocket

     Connection: Upgrade

Just like a "101 Switching Protocols" should indicate which sub-protocol (if any) was accepted ('chat' in this example):

     HTTP/1.1 101 Switching Protocols

     Upgrade: websocket

     Connection: Upgrade

     Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

     Sec-WebSocket-Protocol: chat

I propose that a "426 Upgrade Required" response MUST indicate which protocols (if any) are acceptable:

     HTTP/1.1 426 Upgrade Required

     Upgrade: websocket

     Connection: Upgrade

     Sec-WebSocket-Protocol: chat

This mirrors similar patterns already used in HTTP including a "405 Method Not Allowed" response where the server (from [2]):

   8.4.6.  405 Method Not Allowed

   The method specified in the Request-Line is not allowed for the

   target resource.  The response MUST include an Allow header field

   containing a list of valid methods for the requested resource.

The reason it is a must is that otherwise there is no way for the client to know what to do because the exchange is not self-described.

I think it is fine to reuse the Sec-WebSocket-Protocol header field just like what is done for the 101 response.

Thanks,

Henrik

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8.4.19

[2] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8.4.6

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Thu, 14 Apr 2011 16:45:02 +0000

Not sure whether this was registered as an issue but I believe it is important in order to allow clients to interop with servers.

Thanks,

Henrik

From: [email-masked] [mailto:[email-masked]] On Behalf Of Henrik Frystyk Nielsen
Sent: Thursday, April 07, 2011 10:59
To: [email-masked]
Subject: [hybi] Indicating acceptable protocols in a 426 Upgrade Required Status response

     Upgrade: websocket

     Connection: Upgrade

     Upgrade: websocket

     Connection: Upgrade

     Upgrade: websocket

     Connection: Upgrade

Thanks,

Henrik

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 14 Apr 2011 20:11:18 +0200

Hi Henrik,

yes I have it on my issues' list...

more this issue was brought up during the F2F meeting in Prague,
however it is not clear to me what the wg think about the "426" usage

this should be discussed in the thread initiated yesterday by Takeshi 
about SubProtocol Semantic:
http://www.ietf.org/mail-archive/web/hybi/current/msg07241.html

cheers
/Sal

On 4/14/11 6:45 PM, Henrik Frystyk Nielsen wrote:
>
> Not sure whether this was registered as an issue but I believe it is 
> important in order to allow clients to interop with servers.
>
> Thanks,
>
> Henrik
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Henrik Frystyk Nielsen
> *Sent:* Thursday, April 07, 2011 10:59
> *To:* [email-masked]
> *Subject:* [hybi] Indicating acceptable protocols in a 426 Upgrade 
> Required Status response
>
> The latest HTTP/1.1-bis draft [1] includes a definition of the “426 
> Upgrade Required” status code which was adopted from RFC 2817. This 
> allows a server to send back a response indicating that an upgrade 
> protocol such as WebSocket is required:
>
> Just like a “101 Switching Protocols” should indicate which 
> sub-protocol (if any) was accepted (‘chat’ in this example):
>
> I propose that a “426 Upgrade Required” response MUST indicate which 
> protocols (if any) are acceptable:
>
> This mirrors similar patterns already used in HTTP including a “405 
> Method Not Allowed” response where the server (from [2]):
>
> The reason it is a must is that otherwise there is no way for the 
> client to know what to do because the exchange is not self-described.
>
> I think it is fine to reuse the Sec-WebSocket-Protocol header field 
> just like what is done for the 101 response.
>
> Thanks,
>
> Henrik
>
> [1] 
> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8.4.19 
>
>
> [2] 
> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8.4.6
>

-- 
Salvatore Loreto
www.sloreto.com

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 15 Apr 2011 03:30:50 +0200

>      Sec-WebSocket-Protocol: chat

I don't understand how and when a websocket server is supposed to
reply such 426. For example, if a client sends a correct WebSocket
HTTP handshake request but no one of the listed subprotocols is
supported by the server, do you mean that the server should reply 426
rather than 101?

But it is 100% true that current draft 06 doesn't specify what occurs
in case the server supports no one of the subprotocols suggested by
the client in the Sec-WebSocket-Protocol header. This is a common
issue in the draft: it assumes all goes OK and doesn't care about
possible errors:

- What should do the client if the handshake request receive a 401 or
303 response?

- What should do the server if it supports no one of the subprotocols
suggested by the client in the Sec-WebSocket-Protocol header?

- What should do the client if Sec-WebSocket-Protocol header in 101
response contains a subprotocol not suggested in the client request?
The draft just says: "Web browsers verify that the server included one
of the values as was specified in the |WebSocket| constructor.", but
does not define how the client should react in other case. (Also, why
does the draft say "Web browsers" rather than "WebSocket clients"?).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 15 Apr 2011 03:55:26 +0200

> does the draft say "Web browsers" rather than "WebSocket clients"?).

Sorry, I didn't realize that this exact subject is being discussed in
other mail thread.

-- 
Iñaki Baz Castillo
<[email-masked]>