Re: SPDY Header Frames
Jonathan Ballard <dzonatas@gmail.com> Sat, 14 July 2012 00:13 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CD221F858E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Jul 2012 17:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.698
X-Spam-Level:
X-Spam-Status: No, score=-8.698 tagged_above=-999 required=5 tests=[AWL=1.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3YkdJUXMK7C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Jul 2012 17:13:57 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 01F6321F84FD for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 13 Jul 2012 17:13:57 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Sppyi-0004dl-DL for ietf-http-wg-dist@listhub.w3.org; Sat, 14 Jul 2012 00:12:56 +0000
Resent-Date: Sat, 14 Jul 2012 00:12:56 +0000
Resent-Message-Id: <E1Sppyi-0004dl-DL@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <dzonatas@gmail.com>) id 1SppyP-0004cF-5d for ietf-http-wg@listhub.w3.org; Sat, 14 Jul 2012 00:12:37 +0000
Received: from mail-vc0-f171.google.com ([209.85.220.171]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <dzonatas@gmail.com>) id 1SppyN-0002DT-Bv for ietf-http-wg@w3.org; Sat, 14 Jul 2012 00:12:37 +0000
Received: by vcbgb30 with SMTP id gb30so3081508vcb.2 for <ietf-http-wg@w3.org>; Fri, 13 Jul 2012 17:12:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iaP5PlZEWgXeNJdLpPYUBKtWTgpNpFo52t5myNc2E2g=; b=DSo3KhLGSqKpCQtUYQ+X6736AZU5EqYfpWNaRG/FE5pw4DzPgV2ZlExyeQPmA2Uy7Y NUjOaxFxRomixx3o3cO390TQw8G3wbQpnPAqJucNee3Yal9/D0bE5t+BpNCUTZZ/BjZ3 ljNlhgwZSZX25C8ulT4KbWWqkJnMichF56gzVaZ2aY8raniFcV1iBTaKBBJ9MZ38zXOm UYBiGKz1HlrjHZVcT98HLYoea8jYsx/kLH8QTlDntVHi6hcLTv015Y4z29v0Adr/QNC2 pALSTSoQvs4YZGTZrYHi6vesVgD0Pl5Lyc01QAsC+cmfnSHEbY0O3vRIwal32hGV/L0b V4GQ==
MIME-Version: 1.0
Received: by 10.52.29.176 with SMTP id l16mr1309666vdh.80.1342224729408; Fri, 13 Jul 2012 17:12:09 -0700 (PDT)
Received: by 10.52.115.104 with HTTP; Fri, 13 Jul 2012 17:12:09 -0700 (PDT)
In-Reply-To: <5000B0E5.9000103@zinks.de>
References: <CABP7RbepWH4ahSPHDU_M_w0tRVz_RRm1FV-jM_Y72=YHCVqO0g@mail.gmail.com> <5000B0E5.9000103@zinks.de>
Date: Fri, 13 Jul 2012 17:12:09 -0700
Message-ID: <CAAPAK-76qiRiAOg_wYBQYAb1yMUuR-A4JVcT+OjwgyM5nuS6qg@mail.gmail.com>
From: Jonathan Ballard <dzonatas@gmail.com>
To: Roland Zink <roland@zinks.de>
Cc: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="20cf3078151a34857704c4bf0c0e"
Received-SPF: pass client-ip=209.85.220.171; envelope-from=dzonatas@gmail.com; helo=mail-vc0-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-2.7
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1SppyN-0002DT-Bv 920f4191b9b97f1b66955d1eb731fed1
X-Original-To: ietf-http-wg@w3.org
Subject: Re: SPDY Header Frames
Archived-At: <http://www.w3.org/mid/CAAPAK-76qiRiAOg_wYBQYAb1yMUuR-A4JVcT+OjwgyM5nuS6qg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/14182
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Maybe it's not quite intuitive enough, especially when we cross-reference the similarities of that WAP binary encode with JPEG2000's binary encode, the MIME types specifically: http://www.faqs.org/rfcs/rfc3745.html (and more) I haven't seen any patent that extends those MIME types with either the static index or dynamic index value, which accomplishes the compressed header desired in HTTP2. Sorry, I have no sample for this post. On Fri, Jul 13, 2012 at 4:36 PM, Roland Zink <roland@zinks.de> wrote: > A similar binary encoding for HTTP headers is used in the WAP (Wireless > Application Protocol). The goal there was to reduce the number of bytes so > there are more optimization on size but skipping of values is a bit more > difficult. If anybody is interested the full specification can be found at > http://www.openmobilealliance.org/tech/affiliates/wap/wap-230-wsp-20010705-a.pdf. > The header encoding is in section 8.4. > > Regards, > Roland > > > > On 14.07.2012 00:16, James M Snell wrote: > > This note is intended to provide some additional thoughts for discussion > around the design and use of SPDY as the possible basis for HTTP/2.0. The > intent is to provide fuel for discussion... comments are definitely welcome. > > As discussed within draft-tarreau-httpbis-network-friendly-00, and as has > been mentioned several times in discussion on list, handling of headers > within the current SPDY framing, and in particular the layering of HTTP/1.1 > messages into SPDY frames is less than optimal. There is significant wasted > space, duplication, etc that -- strictly speaking -- really isn't > necessary. While I recognize that the following increases the basic > complexity of the protocol, it allows fairly significant optimization > following the same basic lines of reasoning expressed in > draft-tarreau-httpbis-network-friendly-00. > > Section 2.6.1 of the SPDY draft defines header blocks using the > following format: > > +------------------------------------+ > | Number of Name/Value pairs (int32) | > +------------------------------------+ > | Length of name (int32) | > +------------------------------------+ > | Name (string) | > +------------------------------------+ > | Length of value (int32) | > +------------------------------------+ > | Value (string) | > +------------------------------------+ > | (repeats) | > > This structure is used within SYN_STREAM and HEADERS frames. > > What I propose is the following revised structure: > > +------------------------------------+ > | Number of Headers (int32) | > +------------------------------------+ > |T| Flags (7) | Length (24) | > +------------------------------------+ > | Data | > +------------------------------------+ > |T| Flags (7) | Length (24) | > +------------------------------------- > | Data | > +------------------------------------- > | (repeats) | > > T is a single bit identifying the Header Type. There are two types.. > REGISTERED (0) and EXTENSION (1) > > Flags provides flags for the specific header field. The flag 0x1 > indicates that the header value contains Character Data. If not set, the > value is assumed to consist of raw octets. 0x2 indicates that the value is > compressed. > > Length is an unsigned 24-bit value specifying the number of octets after > the length field. > > When the T bit is NOT set, the Header field is a REGISTERED Header, the > structure of which is: > > +------------------------------------+ > |0| Flags (7) | Length (24) | > +------------------------------------+ > | ID | Value Length (int32) |Value...| > +------------------------------------+ > > The ID is a 32-bit number uniquely identifying the registered field. > Each is assigned by the registrar. For instance, the "Host" field could > have a registered value of "1", the "Accept-Lang" field could have a > registered value of "6", and so forth. > > The Value Length is a 32-bit value indicating the length of the value. > > If Flag 0x1 is set, the value is assumed to contain character data. When > set, the value MUST be preceded by a single unsigned 8-bit integer > identifying the character encoding utilized. The values are assigned by the > registrar. For instance, US-ASCII could have a registered value of "1", > while "UTF-8" could have a registered value of "2". > > For example: > > +------------------------------------+ > |0| 0000001 | 24 | > +------------------------------------+ > | 1 | 16 | 1 | www.example.org | > +------------------------------------+ > > This Header record indicates a REGISTERED header containing character > content, the header ID = 1, the charset used is US-ASCII and the value is " > www.example.org". The header is expressed with a total of 28 bytes. > > When the T bit IS set, the Header field is an EXTENSION Header, the > structure of which is: > > +------------------------------------+ > |0| Flags (7) | Length (24) | > +------------------------------------+ > | Length of name (int32) | > +------------------------------------+ > | Name (string) | > +------------------------------------+ > | Length of value (int32) | > +------------------------------------+ > | Value | > +------------------------------------+ > > For example.. an extension header that contains raw binary data... > > +------------------------------------+ > |0| 0000000 | Length (24) | > +------------------------------------+ > | 5 | > +------------------------------------+ > | x-foo | > +------------------------------------+ > | 4 | > +------------------------------------+ > | {raw bytes} | > +------------------------------------+ > > The header is expressed with a total of 21 bytes. > > The same flags apply. 0x1 indicates that the value is character data. If > 0x1 is not set, the value contains raw octets. The key difference is that > there is a 32-bit name length and variable length name field in place of > the 32-bit ID field in the REGISTERED header. All other details remain the > same. > > As is currently the case in SPDY, if a single header value contains > multiple values, each can be separated using a single NUL (0) byte. > > There are several advantages to this approach: > > 1. Commonly used header names are omitted in favor of registered, known > numeric IDs, saving space and making it more efficient to scan over > commonly used headers. For instance, intermediaries that route requests > based on common headers such as Host etc could choose to ignore EXTENSION > header fields entirely, and scan only for the ID's of the fields they are > interested in, rather than having to parse the entire bag of header names. > > 2. Header values can be expressed as raw octets or character data. > Currently, mechanisms within HTTP require developers to muck around with > Base64 encoding or other encodings when including detail within a header. > This approach would eliminate that extra step. For instance, if I wanted to > have a Content-Integrity header whose value is an hmac digest, I would be > able to drop the raw bytes of the digest into the header value rather than > base64 or hex encoding it into an ASCII string, saving CPU cycles and > reducing the amount of data that must be transmitted. > > 3. Header values that contain character data would not be limited to > US-ASCII. Multiple charset encodings would be allowed... obviously this has > a whole slew of issues associated with it that need to be carefully > considered. The charset encoding flag could be dropped, if necessary, from > this proposal. > > For HTTP/1.1 Compatibility, each REGISTERED Header would be mapped to a > known, registered HTTP/1.1 header, allowing one to one translation from the > optimized form to the HTTP/1.1 form. Binary values would be base64-encoded. > If a particular header does not allow for Base64 encoded values under > HTTP/1.1, the down-level recipient would have the option of responding with > an appropriate 404 response. > > That's it for now. There are additional considerations to be given to > the specific selection of header fields to include within the SYN_STREAM > vs. follow-on HEADERS frames but that's a separate conversation. As always, > feedback is welcome... > > - James > > > >
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Roland Zink
- SPDY Header Frames James M Snell
- Re: SPDY Header Frames Poul-Henning Kamp
- Re: SPDY Header Frames Willy Tarreau
- Re: SPDY Header Frames Poul-Henning Kamp
- Re: SPDY Header Frames Mike Belshe
- Re: SPDY Header Frames Jonathan Ballard
- Re: SPDY Header Frames Roland Zink
- Re: SPDY Header Frames Jonathan Ballard
- Re: SPDY Header Frames Willy Tarreau
- Re: SPDY Header Frames Willy Tarreau
- Re: SPDY Header Frames Poul-Henning Kamp
- Re: SPDY Header Frames Poul-Henning Kamp
- Re: SPDY Header Frames Roberto Peon
- Re: SPDY Header Frames Poul-Henning Kamp
- Re: SPDY Header Frames HAYASHI, Tatsuya
- Re: SPDY Header Frames Willy Tarreau
- Re: SPDY Header Frames Roland Zink
- Re: SPDY Header Frames Roberto Peon
- Re: SPDY Header Frames HAYASHI, Tatsuya
- Re: SPDY Header Frames Amos Jeffries
- Re: SPDY Header Frames Poul-Henning Kamp
- Re: SPDY Header Frames Amos Jeffries
- Re: SPDY Header Frames Amos Jeffries
- Re: SPDY Header Frames HAYASHI, Tatsuya
- Re: SPDY Header Frames James M Snell
- Re: SPDY Header Frames Amos Jeffries
- Re: SPDY Header Frames James M Snell
- Re: SPDY Header Frames Mike Belshe
- Re: SPDY Header Frames James M Snell
- Re: SPDY Header Frames James M Snell
- Re: SPDY Header Frames Poul-Henning Kamp
- Re: SPDY Header Frames Martin J. Dürst
- Re: SPDY Header Frames James M Snell
- Re: SPDY Header Frames Julian Reschke
- Re: SPDY Header Frames Poul-Henning Kamp
- Re: SPDY Header Frames Roberto Peon
- Re: SPDY Header Frames Poul-Henning Kamp
- character encoding in header fields, was: SPDY He… Julian Reschke
- Re: SPDY Header Frames Poul-Henning Kamp
- Re: character encoding in header fields, was: SPD… Amos Jeffries
- Re: SPDY Header Frames Roberto Peon
- Re: SPDY Header Frames Poul-Henning Kamp
- Re: SPDY Header Frames Phillip Hallam-Baker
- Re: SPDY Header Frames Julian Reschke
- Re: SPDY Header Frames James M Snell
- Re: character encoding in header fields, was: SPD… James M Snell
- Re: character encoding in header fields, was: SPD… Julian Reschke
- Re: character encoding in header fields, was: SPD… James M Snell
- Re: character encoding in header fields, was: SPD… Poul-Henning Kamp
- RE: character encoding in header fields, was: SPD… Robert Brewer
- Re: character encoding in header fields, was: SPD… James M Snell
- Re: SPDY Header Frames Patrick McManus
- Re: character encoding in header fields, was: SPD… Julian Reschke
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… James M Snell
- Re: SPDY Header Frames James M Snell
- Re: SPDY Header Frames Nicolas Mailhot
- Minimizing/avoiding User-Agent, was: SPDY Header … Julian Reschke
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Nicolas Mailhot
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Nicolas Mailhot
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Poul-Henning Kamp
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Karl Dubost
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Poul-Henning Kamp
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Karl Dubost
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Karl Dubost
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Poul-Henning Kamp
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Nicolas Mailhot
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Julian Reschke
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Karl Dubost
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… James M Snell
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Poul-Henning Kamp
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Karl Dubost
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Poul-Henning Kamp
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… James M Snell
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Mark Nottingham
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… Martin J. Dürst
- RE: Minimizing/avoiding User-Agent, was: SPDY Hea… Anil Sharma
- Re: Minimizing/avoiding User-Agent, was: SPDY Hea… James M Snell