Re: BLOCKED frame specification

What about working within the PING frame, and making a gentleman’s agreement? It’s a conforming extension anyway:

1. If a stream seems to be blocked, send a PING with the first 4 bytes being the stream ID and next 4 bytes indicating some CHECK_BLOCKED opcode constant.

2. If the stream is indeed blocked, the server sends a PING with the stream ID, a CONFIRM_BLOCKED opcode, and the ACK bit already set.

3. In any case, if the connection is OK (which is likely in question, too), the server sends a matching reply PING. If this is received before any CONFIRM_BLOCKED, the query returns not-blocked.

An additional CONFIRM_NONBLOCKED opcode would allow distinguishing a server without the extension from a non-blocked stream, although I imagine implementations would be susceptible to false NONBLOCKED results.

For what it’s worth, I don’t see what’s wrong with being more specific about PING payloads. If it’s too much to standardize this, perhaps make some kind of registry as there is for methods.


On 2014–04–16, at 9:06 AM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> It'd be interesting in hearing why not. Do you think it's net-negative, or is it a question of time/prioritization? And would you oppose specification even if you didn't implement?
> 
> As Roberto points out, this is more about tuning than just debugging. If things are outright hanging, we can probably debug that. But if performance is just crappy, it is often non-obvious to folks how to debug that. It's my hope that a BLOCKED frame would allow the common webservers to track stats for BLOCKED frames to make it easier to flag these performance tuning issues, rather than having to manually dive into traces, which I don't expect most deployments to do. I may very well be overly-concerned here, but I fear that many will enable HTTP/2 with flow control, and it will "work", but be slow, and people will blame HTTP/2 and not adopt. That would be unfortunate.

Received on Wednesday, 16 April 2014 10:01:07 UTC