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: Patrick McManus <mcmanus@ducksong.com>
Date: Wed, 04 Apr 2018 13:11:34 +0000 (UTC)
Message-ID: <CAOdDvNrccM+sdn68R6rryWnQtOM4w8fKyhs3_cesgCaA1gW35w@mail.gmail.com>
To: Loïc Hoguin <essen@ninenines.eu>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>
On Wed, Apr 4, 2018 at 8:43 AM, Loïc Hoguin <essen@ninenines.eu> wrote:

> Assuming a resource is only configured for Websocket use, how would you
> reject incoming HTTP/2 requests that don't use the extended CONNECT?

I think you're asking specifically about a CONNECT request on a resource
that expects h2ws but doesn't include the new pseudoheader? I would
probably return a 400.

> 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.

yeah, I think a generic response code is your best bet here too. I'm
curious, do you think the 426 added anything of value (beyond human
readable info which can go in the message body) to the original error path?
i.e. could a client automatically do anything with that?

> 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?

if the resource doesn't support the CONNECT method, then 405 is a good
choice imo

> Cheers,
> --
> Loïc Hoguin
> https://ninenines.eu
Received on Wednesday, 4 April 2018 13:12:03 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:59 UTC