Re: Stuck in a train -- reading HTTP/2 draft.

On 2014–06–19, at 3:18 AM, Jason Greene <jason.greene@redhat.com> wrote:

> I share this opinion. The priority frames introduce way too much complexity for what is essentially a hint. Assuming it’s followed, it’s possible that the processing overhead of client directed scheduling might end up causing the very problem it’s intending to address.

Anyone attempting to implement it should know enough to use an algorithm of known O(1) computational complexity, although O(log N) choices are also viable.

> Finally, since HTTP/2 is already over TCP, send order already offers clients a mechanism for assigning priority (although admittedly a bit basic).

This only works as long as the server processes requests serially, which isn’t even possible with a reverse proxy. And it moves the scheduling complexity to the client side, which now must defer low-priority requests. Terrible architecture.

Also, stream initiation order is not preserved by intermediaries, so TCP’s guarantee is not strong enough.

Received on Tuesday, 24 June 2014 07:08:46 UTC