Re: Fragmentation for headers: why jumbo != continuation.

>
> > Conclusion based on corrected arguments is quite the opposite:
> > - Fragmentation offers server as sender (or client as sender too)
> > ability to freely cause HOL-block or stall/DoS the connection with
> > multiple end-clients suffering.
> > - Fragmentation causes state commitment increases in proxies.
>
> +1. I reached the same conclusions and it was the last straw that caused
> me to suspend my implementation effort.
>
> Header streaming does not practically reduce state commitment for a proxy
> which coalesces connections. Coalescing is one of the most promising
> aspects of HTTP/2 for me. It would seem to be a must for reverse proxies,
> but yet it also seems impossible to accomplish according to the spec.
>

A typical reverse proxy will want to buffer full header sets on the request
path to prevent HOL blocking on coalesced connections to backends. However
it could reasonably stream fragments on the response path, from trusted
backends.

As such a proxy now doesn't need to commit to buffering full response
header sets (they're processed incrementally), it has reduced it's state
commitment.

Received on Sunday, 13 July 2014 17:16:03 UTC