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

On 04/04/2018 03:11 PM, Patrick McManus wrote:
> 
> 
> On Wed, Apr 4, 2018 at 8:43 AM, Loïc Hoguin <essen@ninenines.eu 
> <mailto: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.

Sorry. I meant a GET or other non-CONNECT. I guess a 405 would be the 
way to go for this particular case.

For CONNECT requests lacking a :protocol pseudoheader but containing a 
:scheme or :path I reject them as malformed very early on as per 
https://tools.ietf.org/html/rfc7540#section-8.3

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

In Websocket's case I have not seen it be useful in practice beyond 
human readable info.

In theory if the 426 response contained Upgrade: websocket and a 
sec-websocket-protocol header it could be potentially useful to 
automatically detect functionality (like a REST API also having a 
Websocket endpoint for STOMP or MQTT) but I haven't heard of anyone 
doing this in practice. This could be described in the response body anyway.

400 it is.

>     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

Thanks!

Cheers,

-- 
Loïc Hoguin
https://ninenines.eu

Received on Wednesday, 4 April 2018 14:26:56 UTC