- From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Date: Wed, 15 Oct 2014 11:45:31 +0300
- To: Adrian Cole <adrian.f.cole@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Oct 14, 2014 at 11:01:01PM -0700, Adrian Cole wrote: > I had a look at a websocket over http/2 draft yesterday. I noticed it > saying we should return an http 501 upon some setting thing not > working out. > > https://github.com/yutakahirano/ws-over-http2/blob/master/draft-hirano-websocket-over-http2.txt#L235 > > This made me scratch my head, as I implement http/2 framing, settings, > etc than the layer than handles http semantics (eg what a 501 means). > IOTW, I would have expected an extension to enumerate an error I'd > send on goaway, not an http response code. The negotiation and the 501 in that draft makes no sense to me: 1) It uses ALPN anyway. That already impiles negotiation (the N in ALPN). 2) Even if it didn't use ALPN, the client does not have to tell server it supports Websockets. 3) That message is not even an ACK to server's report of support of Websockets (there is no SETTINGS from server to client). 4) If client doesn't support Websockets, it won't use Websockets, so it is pointless to refuse requests with a 501. I would have just setting server to client (hard-enabled in presence of ALPN, enableable otherwise) and no 501. -Ilari
Received on Wednesday, 15 October 2014 08:45:56 UTC