Subject: Extensions and error codes

From: Adrian Cole <[email-masked]>
Date: Tue, 14 Oct 2014 23:01:01 -0700

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.

As an implementor, I would handle code very differently if something
in SETTINGS means I should return a specific HEADERS frame back.

Looking at the spec, it doesn't specify on what types of actions we
might take on a SETTING being unsupported. Should we be?
https://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-5.5

Apologies, if I missed a thread that discussed this.
-A

---

From: Adrian Cole <[email-masked]>
Date: Tue, 14 Oct 2014 23:58:26 -0700

I suppose this wording indirectly covers it.

"extensions that could change the semantics of existing protocol components MUST
be negotiated before being used..." [1]

By virtue of overriding how existing frames are used, it could decide
to return errors as http responses as opposed to doing that in the
framing layer as goaway, reset, etc.

It is an interesting problem to solve, portably allowing extensions
who have a lot of leeway. Might be another column for the
Implementations Wiki: "extension support" Always nice to see how
others handle these things.

-A

[1] https://github.com/http2/http2-spec/blob/master/draft-ietf-httpbis-http2.xml#L1540

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 15 Oct 2014 11:45:31 +0300

> 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