- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Fri, 11 Jul 2014 10:04:51 +0000
- To: Greg Wilkins <gregw@intalio.com>
- cc: Jeff Pinner <jpinner@twitter.com>, HTTP Working Group <ietf-http-wg@w3.org>
In message <CAH_y2NFa3x6Gn4A_OpP+coRR1UE5VdO6SgE6y4NoAreZ=y=07Q@mail.gmail.com>, Greg Wilkins wri tes: >1) Increase frame size to 16-bits I still think this is horribly near-sighted and first rate false economy. >1a) Add a settings for max_frame_size For reasons of interop I would add: 1b) This setting must be configurable to 16384 bytes. 1c) Settings below 256 bytes are illegal. This establishes a configurable "we know this will work" and ensures that it is always possible to get /robots.txt. >2) Remove reference set from HPACK allowing for "streaming" decoding. >3) Requiring that all ":"-headers appear first. YES! >4) Only allowing CONTINUATION if the previous frame is max_frame_size. So what exactly happens if a complete header doesn't fit into the frame ? Does HPACK keep per-stream state ? >5) Allowing interleaving of CONTINUATION frames with other frames. "with other frames" or "with all other frames" ? Can we please also move the END_STREAM bit to the last CONTINUATION ? >5b) The size of the HEADERS and CONTINUATION frames are removed from the >flow control window, but the they are never flow controlled. I think they should be flow controlled on the connection window, that way the connection window can be used to balance competing connections for a contested resource. -- 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 Friday, 11 July 2014 10:05:15 UTC