- From: Jason Greene <jason.greene@redhat.com>
- Date: Thu, 17 Jul 2014 12:04:33 -0500
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Jul 16, 2014, at 11:44 PM, Mark Nottingham <mnot@mnot.net> wrote: > > On 17 Jul 2014, at 1:42 am, Jason Greene <jason.greene@redhat.com> wrote: > >> >> On Jul 16, 2014, at 9:53 AM, Greg Wilkins <gregw@intalio.com> wrote: >> >>> >>> On 16 July 2014 17:08, Mark Nottingham <mnot@mnot.net> wrote: >>> Are there any other realistic (i.e., capable of achieving consensus, NOT just your favourite approach) options that we should be considering? >>> >>> hmmmm I am probably being unrealistic.... but let's tilt at this windmill >>> >>> c) Remove CONTINUATION from the specification, allow HEADERS to be fragmented and add a new setting that advises the maximum header set size (i.e,. uncompressed) a peer is willing to receive (but might not imply PROTOCOL_ERROR or STREAM_ERROR on receipt). >> >> I have a fourth option to add to the mix which is based on all of the feedback I have seen. >> >> AFAICT there is only one limited use-case that can not be covered by the recent move to allow large frames. That is the ability to split a frame into chunks so that a 1:1 proxy doesn’t have to buffer. >> >> We could have a more narrow form of CONTINUATION: >> >> - The sum of all continuation frames can not exceed max_frame_size. > > The default of max_frame_size is 16k; that means that a server can't ever send more than 16k (or 32k, depending on whether you intend to include HEADERS in the max) of response headers without some adjustment by the browser… 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. If you compare CONTINUATION to Large Frames, they are actually very similar. They both: - Can send very large headers - Block other streams until completion - Support writing to the wire in chunks Continuations adds: - 16MB -> Unlimited headers - Ability to write in chunks without knowing the total compressed length The former is not really desirable and causes #551. The latter offers very limited value, in that a 1:1 proxy can re-encode the frame using different hpack state and send the data across in piecemeal. So this option is simply saying we can address that particular use-case, if deemed important, by supporting fragmentation of the HEADERS frame. We don’t have to span frames to accomplish the need. By not spanning frames we solve #551, and also eliminate the DOS exposure concern which has been brought up against a header size limit solution. > > >> Since this use case is avoiding buffering, they may not know the exact size has exceeded the max until the Nth continuation is sent. Therefore: >> >> - Add a discard flag on the last HEADER/CONTINUATION frame, which instructs the endpoint to discard the request and all buffered data. > > Why not just reset the stream? The only benefit in not reseting the stream is just notifying the server that a request wasn’t sent because it was too big. Although I agree its of limited value. It was a concern brought up against size limits, that a server does not know when a request is too big. I personally disagree with the concern, I just was describing one way it could be handled. > > >> Pros: >> - Addresses 551 >> - There is only one max setting >> - Encourages reduction of gigantic headers >> - As a side-effect of the discard flag, it provides a client the ability to inform the server that a request was too large and would have generated a 431 (not really significant but it came up in a thread and worth mentioning) >> >> Cons: >> - As with all other length limited proposals, sender has to rewind encoder state to that of last sent frame. > > Cheers, > > > -- > Mark Nottingham https://www.mnot.net/ > > > > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Thursday, 17 July 2014 17:05:08 UTC