- From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Date: Tue, 2 Sep 2014 16:48:33 +0300
- To: Cory Benfield <cory@lukasa.co.uk>
- Cc: Greg Wilkins <gregw@intalio.com>, "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Sep 01, 2014 at 08:46:50AM +0100, Cory Benfield wrote: > > I think that if we make any of the (relatively substantial) changes > Roy is suggesting we'll want to go back and look really hard at the > division between the framing layer and the semantic layer. What I think is one way to change that division (going a bit further than Roy's suggestions): Frame header: - Frame format changed to (stream(32)+type(8)+length(24)). - Frame types with always zero / always nonzero stream ID can share a frame type[1][2]. Header blocks: - The whole header block is sent at once (no CONTINUATION). Header blocks are extempt from frame size limits[3][4]. - If header block creates a stream, :scheme has to be first[5]. - Unknown :scheme (in stream creation) triggers stream error[6]. - All header names and values are 8-bit clean. No ordering restrictions except one noted above. - Schemes can place limits on valid header names, values and ordering (stream error to violate). Flags: - END_STREAM is replaced by END_STREAM frame. - PADDED is replaced by PADDING frame. - END_HEADERS is removed (no CONTINUATION). - PRIORITY is removed (use PRIORITY frame). - ACK is replaced by SETTINGS_ACK / PONG frames. Frame sequencing: - Stream frame sequencing at framing level is only constrained by the stream state machine. - Schemes may have further restrictions (stream error to violate)[7]. Push: - SETTINGS_ENABLE_PUSH can be set to 1 in both directions (HTTP will reset stream if you try to push client-to-server). This removes most HTTP-specific stuff from the framing layer (except for SETTINGS space and error codes space)[8]. [1] Vast majority of frames would only be valid for one of those and one would have to check anyway. [2] RST_STREAM/GOAWAY and WINDOW_UPDATE should have the same numbers. [3] CONTINUATION already busts frame size limits and interactivity just as bad. [4] Incentive to not send excessive headers, 16MB is darn near infinite for present purpose. [5] For header streaming to work, it has to be first. [6] Responding at HTTP level no longer works. [7] Things like not starting response with a DATA frame in HTTP. [8] CONNECT_ERROR, description of SETTINGS_MAX_HEADER_LIST_SIZE. -Ilari
Received on Tuesday, 2 September 2014 13:49:00 UTC