- From: ??? <willchan@chromium.org>
- Date: Sun, 20 Jan 2013 15:21:28 -0800
- To: HTTP Working Group <ietf-http-wg@w3.org>
Indeed. It might be something similar to https://code.google.com/p/spdyshark/. Or spdycat (https://github.com/tatsuhiro-t/spdylay). On Sun, Jan 20, 2013 at 3:15 PM, David Morris <dwm@xpasc.com> wrote: > > > 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:21:55 UTC