Re: Extensions and error codes

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

On Tue, Oct 14, 2014 at 11:01 PM, Adrian Cole <adrian.f.cole@gmail.com> 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.
>
> 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

Received on Wednesday, 15 October 2014 06:58:53 UTC