W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: Working Group Last Call: Bootstrapping WebSockets with HTTP/2

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>
Message-ID: <a8658e92-ef2c-653f-c78c-dc373558a379@ninenines.eu>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:20 UTC