W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

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

From: David Morris <dwm@xpasc.com>
Date: Sun, 20 Jan 2013 15:15:41 -0800 (PST)
cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <alpine.LRH.2.01.1301201514090.15390@egate.xpasc.com>


On Sun, 20 Jan 2013, Willy Tarreau wrote:

> Hi Pablo,
> 
> On Sun, Jan 20, 2013 at 07:20:25PM -0300, Pablo 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).
> 
> As much as I love to read HTTP protocol in network traces or in programs,
> I must say that we (humans) are very rare HTTP readers. I suspect that only
> something like 1 request on 1 billion is read by a human. This is not a great
> enough ratio for keeping an ambiguous, complex, and sometimes even insecure
> protocol to parse.
> 
> I too tried as much as I could to see what would be achievable with a text
> based protocol, but I finally admitted it was a dead end. At the moment the
> challenges consist in feeding requests as fast as possible over high latency
> connections and processing them as fast as possible on load balancers and
> caches in order to maintain a scalable internet. Humans are very incapable
> devices there.

It won't be rocket science to create a plugin for Wireshark/etherial and
other network tools which can format the binary data for those cases where
humans need to do that for debugging.
Received on Sunday, 20 January 2013 23:16:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 20 January 2013 23:16:13 GMT