- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 17 Jul 2014 10:20:25 -0700
- To: Jason Greene <jason.greene@redhat.com>
- Cc: Mark Nottingham <mnot@mnot.net>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 17 July 2014 10:04, Jason Greene <jason.greene@redhat.com> wrote: > Right. The thinking there is that 99.8% of headers are < 16K, so this is more than enough, and when you have a .2% you can just bump the frame size. Here my only concern is that you don't have any way of triggering this bump. Say we got rid of CONTINUATION... What does a client do if it prefers to have 16K frames? How does a server indicate that it wants to send headers that exceed this limit? Flip that around: how does a client indicate that it wants to send headers that exceed this limit? At least a server can send a response... and it has a stream upon which to send it. Browsers, which compete on soul tolerance (thanks Carsten), now have a strong incentive to advertise > 16K frame sizes. I think that you will find that this is an outcome that browser will be especially unhappy with. >> Why not just reset the stream? I think that resetting a stream is the only good response (with an optional 431). I don't know what you would invent something else that has the same net effect.
Received on Thursday, 17 July 2014 17:20:52 UTC