Extensibility framework

[Lukasa]

HTTP/2 is extendable: it's one of its great strengths. It would be really nice if H2 was relatively easily extensible. We should aim to start supporting pluggable HTTP/2 extensions.

What do we need to do this? Well, the answer is: what can extensions do?

• They can add new frames. This means we need to be able to add:
  • new frame types that can be successfully parsed;
  • new transitions in the state machine, both connection and stream, that occur when a new frame is received;
  • specific frame callbacks, both connection and stream, that allow manipulating the connection and stream objects;
  • allow new frames to follow the state machine transitions and callbacks of a pre-existing frame;
• They can add new state machine transitions in the absence of new frames, or adjust the existing state machine transitions;
• They can add new settings. We need to be able to inject useful representations of settings, and allow callbacks for those settings if they're changed;
• They can add new error codes.

This will also require work in hyperframe.

[Lukasa]

We should pick a few example extensions and make them available as fully supported options. Some interesting options are probably:

• @phluid61's compressed data frames (draft-kerwin-http2-encoded-data)
• my own P2P extension (draft-benfield-http2-p2p)
• alt-svc

Being able to implement these cleanly would be a good indication that whatever approach we come up with is probably flexible enough to support a wide variety of extensions.

[phluid61]

A worthy goal. I'm having an existential crisis with draft-kerwin-http2-encoded-data because I'm not confident HTTP/2's extensibility model is sufficient to support it.

If a sender (erroneously) sends a GZIPPED_DATA frame to a receiver that doesn't know of the extension, the recipient MUST discard the frame, so data is lost, but there's no way to detect the problem and no way to fail or recover.

alt-svc seems like an obvious extension to target, because it seems to have the most inertia and potential support.

[Lukasa]

@phluid61 Have you considered using the "advertise support with SETTINGS field" logic I'm using in draft-benfield-http2-p2p? Basically, you can't send GZIPPED_DATA unless the remote peer has sent a SETTINGS_SUPPORT_GZIPPED_DATA = 1 first?

[phluid61]

@Lukasa indeed [1], but it still has the potential to make bugs destructive and hard to detect. Normally when we have a MUST (NOT) it can be backed up with an "or else" error, and I feel really uneasy about the lack of one here.

[Lukasa]

Is it worth mentioning that problem on the mailing list?

[phluid61]

Yeah, I've been sitting on it, waiting to see if I came up with a solution. I think I'll ask my betters peers for their advice. (Also sorry for hijacking your issue.)

[Lukasa]

This wasn't hijacking, it was useful discussion! It means when the thread comes up on the ML I'll be able to jump in more helpfully!