- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Thu, 17 Jul 2014 12:38:33 +0000
- To: Glen Knowles <gknowles@ieee.org>
- cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
In message <CAJCH0yDw8xDS9fo+wDDsY8OsTftsvHtUhaEiDsZpiQ9yOyDpKA@mail.gmail.com>, Glen Knowles wri
tes:
>As a multithreaded sender with a shared compression context it's very hard
>to work with a limit of the compressed size before it's too late.
I think the proper solution would be to add an 'opcode' to HPACK that
means "reset to initial state".
One of the biggest risks of HPACK is that the two ends get out of sync
and the result is going to be really strange headers really fast which
means really strange errors comming back[1].
In that situation, the sender is currently forced to abandon the connection
and open a new to get a fresh compression state.
Having an opcode to move to start[2] that would be much cheaper.
Poul-Henning
[1] Now that I think about it, that's actually a very good argument
for including a 100-Continue like facility.
[2] Do not collect 200 :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Thursday, 17 July 2014 12:38:57 UTC