Re: CONTINUATION was: #540: "jumbo" frames

On 27 June 2014 07:55, Greg Wilkins <gregw@intalio.com> wrote:
> So we are attempting to use what ever market influence we have to discourage
> other end points from implementing this part of the spec - because as you
> may have noticed - we think such an ugly unmotivated mechanism does not
> belongs anywhere near the specification.
>
> We are prepared to spend extra resources on each connection in order to gain
> the benefits of h2.  But we are drawing a line at continuations and we are
> just saying NO period. We will not support them and clients that wish to use
> them will just have to be content with failing when used against jetty
> servers and other implementations that take a similar position.

This is almost certain to be successful.

Either an extension will be implemented that allows negotiation of
CONTINUATION use to detect intermediaries like Jetty that don't accept
them or many clients will simply stop emitting them. Hyper doesn't,
and based on the skeptical reactions from the intermediary providers
in this thread I'm not incentivised to add support for them. All that
will happen is that I'll be inundated with bug reports that tell me
that Hyper doesn't work with Jetty, and I guarantee that my response
of "this is technically Jetty's responsibility" will not go down well.

Interop is more important to me than the moral high ground of
spec-compliance. I'd be quite happy for this WG to postpone WGLC to
come up with a new solution that addresses the concerns of the
intermediaries. As for the proposed alternative approaches:

I'm happy on an implementation level with jumbo frames, either as a
HEADERS-only property or more generally. I appreciate that there's a
concern around using large frames for DATA because of how that affects
muxing, so I'm happy to limit the jumbo frames to HEADERS only.
Negotiation around this property allows for nice fallback behaviours,
where talking directly to endpoints allows use of large header sets,
while intermediaries can push responsibility for large header blocks
onto clients.

I'm less delighted about muxable (i.e. HPACK-free) CONTINUATION
frames, though they might be a better middle-ground solution.
Implementing them intelligently is a bit awkward and requires a
substantial amount of care from the emitting party. It also lays traps
for the unwary such that a single large HTTP header can affect the
compressibility of several following requests. Careful language in the
RFC might be able to get around this point.

I wouldn't push back on either of those two proposals: I have no
specific technical objections to either. I do see some technical
problems with jumbo DATA frames, but if they're negotiated then some
well-chosen language in the RFC suggesting 16kB frame sizes might be
enough. It provides the option to use jumbo DATA frames and warns
about the potential footgun.

Received on Friday, 27 June 2014 08:05:49 UTC