Re: The use of binary data in any part of HTTP 2.0 is not good

[William Chan (陈智昌) <[e-mail]>]

Tim's question can already be partially answered. See the SPDY
whitepaper (http://www.chromium.org/spdy/spdy-whitepaper). I quote:
"Header compression resulted in an ~88% reduction in the size of
request headers and an ~85% reduction in the size of response headers.
On the lower-bandwidth DSL link, in which the upload link is only 375
Kbps, request header compression in particular, led to significant
page load time improvements for certain sites (i.e. those that issued
large number of resource requests). We found a reduction of 45 - 1142
ms in page load time simply due to header compression." I say that
this counts as the answer, because from a human's perspective, the
difference between header compression and bohe is marginal. It's
binary. Yes, maybe some humans will internalize a binary encoding of
headers and be able to grok hexdumps, but to the vast majority of
people, it's basically the same.

Yes, there are other concerns too, such as CPU/memory issues. Also,
that's a qualitative difference in terms of simplicity of parsing by
machines. Patrick wrote up a good explanation here:
http://news.ycombinator.com/item?id=4933567.

On Sun, Jan 20, 2013 at 3:36 PM, James M Snell <[e-mail]> wrote:
> This is still being worked out really, qualitative numbers will be coming.
> So far, however, we're talking about around a 50% reduction in header
> overhead on the wire without compression. Obviously, however, we're no where
> near being done yet.
>
> On Jan 20, 2013 3:26 PM, "Tim Bray" <[e-mail]> wrote:
>>
>> Would it be possible to be data-driven?  Textual formats are
>> well-known to be easier to debug; but clearly, if there’s a
>> substantial performance benefit to going all-binary, so be it. So what
>> is the advantage, quantitatively? -T
>>
>> On Sun, Jan 20, 2013 at 3:04 PM, Mark Nottingham <[e-mail]> wrote:
>> > In one of our recent meetings, one of the grey-bearded IETF old-timers
>> > (I forget which, sorry) said that a textual-protocol was a nice-to-have, but
>> > that it shouldn't be a determining factor in design.
>> >
>> > I.e., if you can get everything you need out of a protocol, *and* make
>> > it textual, do so, but if it detracts from the value you get from it, don't
>> > let that constrain you.
>> >
>> > FWIW, I think that's a good rule of thumb. However, this means that the
>> > community is going to need *excellent* tooling for analysing, debugging,
>> > etc. HTTP traffic; and I don't just mean a Wireshark plugin!
>> >
>> > Cheers,
>> >
>> >
>> > On 21/01/2013, at 9:36 AM, William Chan (陈智昌) <[e-mail]>
>> > wrote:
>> >
>> >> There are many advantages to using binary data. If you would like a
>> >> textual representation of a protocol, I advise using a utility to
>> >> generate one for you.
>> >>
>> >> On Sun, Jan 20, 2013 at 2:20 PM, Pablo <[e-mail]> wrote:
>> >>> Hello,
>> >>>
>> >>>   I have readed this document
>> >>> http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1 today
>> >>> [1].
>> >>>
>> >>> I just wanted to say that I think that the use of any binary data
>> >>> (framing,
>> >>> header compression, etc.) in any place of the "header" part of HTTP
>> >>> protocol
>> >>> is not good; so, please only use plaintext for HTTP 2.0 because,
>> >>> otherwise,
>> >>> that will make very difficult to "see" the headers's protocol :)
>> >>>
>> >>> Thats all,
>> >>> Thanks for reading this few lines, sorry for my basic English, and I
>> >>> hope
>> >>> that you can re-think all this of using binary data in any part of
>> >>> HTTP X.X
>> >>> (ej: session layer).
>> >>>
>> >>>
>> >>> [1] I started knowing about HTTP 2.0 here:
>> >>> http://webscannotes.com/2012/10/09/http-2-0-officially-in-the-works/
>> >>>
>> >>
>> >
>> > --
>> > Mark Nottingham   http://www.mnot.net/
>> >
>> >
>> >
>> >
>>
>