- From: Loïc Hoguin <essen@ninenines.eu>
- Date: Wed, 4 Apr 2018 14:43:35 +0200
- To: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Patrick McManus <mcmanus@ducksong.com>
On 03/28/2018 11:48 PM, Mark Nottingham wrote: > Hi everyone, > > Patrick (as editor) has incorporated the discussion from London and believes this is ready for WGLC; there are no open issues. > > Please have a look at: > https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-01 > > ... and bring up any issues on-list or on its issues list; likewise statements of support (or otherwise) for publication on-list would be appreciated. Assuming a resource is only configured for Websocket use, how would you reject incoming HTTP/2 requests that don't use the extended CONNECT? Or requests that use the extended CONNECT but with an incorrect :protocol value? I have been using 426 with HTTP/1.1 but it only seems adequate for the HTTP/1.1 Upgrade mechanism. How would you reject extended CONNECT requests in the case where the server is properly configured to accept them, the client's request is correct but the resource configured for the given :path refuses to use Websocket? In HTTP/1.1 requests the Upgrade header could be ignored and a normal HTTP response sent back. Would you recommend using the status code 405 for HTTP/2? Cheers, -- Loïc Hoguin https://ninenines.eu
Received on Wednesday, 4 April 2018 12:44:13 UTC