3 ms·

> First, ASCII is inefficient. People don't interpret HTTP, computers do. I can't tell you how many times I've manually read HTTP. To be sure, it's insignifica

> First, ASCII is inefficient. People don't interpret HTTP, computers do. I can't tell you how many times I've manually read HTTP. To be sure, it's insignificant compared to how many HTTP headers have passed through my computer unseen by me. ASCII may be inefficient, but computers are really fast, people are not. I don't have any measurements, but in making a browser, HTTP header parsing/writing was never near a performance issue. Bandwidth wise it also tiny compared to that image file you'd inevitably download for every page visit. And sometimes you don't have tools. Sometimes you don't want tools. Sometimes you want to use tools that work with text to analyse your problem. (You other arguments might still stand, though :) )

FlyingAvatar 13y ago
> HTTP header parsing/writing was never near a performance issue. Since header lengths are not limited, and a single TCP packet's payload is quite limited, long headers can cause very measurable latency difference. Additionally, while I agree the generation / parsing overhead is probably quite small, saving it for every HTTP request is still a boon. I'm also curious where you are reading raw HTTP from? For me it's primarily in two situations, reading a packet capture from WireShark, or in the browser's debugger. In both cases, the tool will end up translating the request for me.
- alayne 13y ago
  I guess a lot of people here never had to work with the X protocols like X.400 and X.500. When you need specialized tools for every protocol and encoding format, development is a real drag. Just because I use Charles or Wireshark doesn't mean that I only want to use those specialized tools. I have definitely been in situations where I'm doing something like running nc as a proxy and looking at raw HTTP. I wouldn't choose to throw that away and revert to the bad old days without a big win.
  - BHSPitMonkey 13y ago
    Should your willingness or unwillingness to use a tool for these (rare) scenarios influence the design of the protocol in any substantial way?
  - peterwwillis 13y ago
    The nc example is the last bastion of this argument. But what about SSL? For a long time you just couldn't test it, or maybe use OpenSSL's server feature piped to nc. But now nc supports SSL natively, making it super easy. Just as it will support binary HTTP natively, making it super easy. And everyone will finally stop caring about ASCII.
- bajsejohannes 13y ago
  > saving it for every HTTP request is still a boon I'm questioning the measurability of this, though. Smells like premature optimization. You could be right, but I'd like to at least measure it before we go about changing one of the fundamental protocols on the internet. Last time I read raw HTTP was when writing a script to automate some stuff on a web page. I specifically did not want the browser's headers and behaviors. I had a bug which only happened from my script, and raw HTTP helped me track it down. I could have used wireshark, but I am much faster in vim for a simple task like that.
  - peterwwillis 13y ago
    HTTP has existed for over 20 years. We've had some time to look at it. It has been measured. As a comparison to your scripting story, you would use Wget or Curl or LWP::UserAgent or a thousand other things to automate HTTP requests. One function call to do what you did manually. To find bugs you would use an HTTP fuzzer like Skipfish to automate the process. If you think somehow your manual process was faster, I say to you, teach a man to fish... (I automate things in web pages for a living, and I only use tools like Firebug and LWP)
__a 13y ago
Calling ASCII a primary source of inefficiency that needs to be "fixed", in the presence of so much rubbish (advertising) being force fed to users by so many websites, is a red flag that this is not truly concerned with efficiency for users' benefit. It may be more concerned with efficiency for those serving up the rubbish. There are other sources of inefficiency that one could argue are much larger sources of inefficiency for end users. Unwanted advertising could be at the top of the list. Resolving domain names of ad servers that serve the user no intentionally requested content, day after day, might be another. True "efficiency" would be embodied by the user receiving only what she requests (the content), and nothing more. A question to ask might be: will a binary protocol make this easier or more difficult for users to achieve? In a vacuum, absent any surrounding context, binary does trump ASCII for efficiency in transmitting and receiving information over a wire. No contest. But in the context of the world wide web, which is a visual medium to be read by humans, moving to a binary protocol does not guarantee that the web will become more "efficient" for end users. If I am an advertiser and can more efficiently insert rubbish into the content the end user is seeking, does that make the web more "efficient"? And who is it that is responsible for 95% of the revenue of the company that designed SPDY/HTTP 2.0? End users? Guess again. The answer is: advertisers.

FlyingAvatar 13y ago

> HTTP header parsing/writing was never near a performance issue. Since header lengths are not limited, and a single TCP packet's payload is quite limited, long headers can cause very measurable latency difference. Additionally, while I agree the generation / parsing overhead is probably quite small, saving it for every HTTP request is still a boon. I'm also curious where you are reading raw HTTP from? For me it's primarily in two situations, reading a packet capture from WireShark, or in the browser's debugger. In both cases, the tool will end up translating the request for me.

alayne 13y ago
I guess a lot of people here never had to work with the X protocols like X.400 and X.500. When you need specialized tools for every protocol and encoding format, development is a real drag. Just because I use Charles or Wireshark doesn't mean that I only want to use those specialized tools. I have definitely been in situations where I'm doing something like running nc as a proxy and looking at raw HTTP. I wouldn't choose to throw that away and revert to the bad old days without a big win.
- BHSPitMonkey 13y ago
  Should your willingness or unwillingness to use a tool for these (rare) scenarios influence the design of the protocol in any substantial way?
- peterwwillis 13y ago
  The nc example is the last bastion of this argument. But what about SSL? For a long time you just couldn't test it, or maybe use OpenSSL's server feature piped to nc. But now nc supports SSL natively, making it super easy. Just as it will support binary HTTP natively, making it super easy. And everyone will finally stop caring about ASCII.
bajsejohannes 13y ago
> saving it for every HTTP request is still a boon I'm questioning the measurability of this, though. Smells like premature optimization. You could be right, but I'd like to at least measure it before we go about changing one of the fundamental protocols on the internet. Last time I read raw HTTP was when writing a script to automate some stuff on a web page. I specifically did not want the browser's headers and behaviors. I had a bug which only happened from my script, and raw HTTP helped me track it down. I could have used wireshark, but I am much faster in vim for a simple task like that.
- peterwwillis 13y ago
  HTTP has existed for over 20 years. We've had some time to look at it. It has been measured. As a comparison to your scripting story, you would use Wget or Curl or LWP::UserAgent or a thousand other things to automate HTTP requests. One function call to do what you did manually. To find bugs you would use an HTTP fuzzer like Skipfish to automate the process. If you think somehow your manual process was faster, I say to you, teach a man to fish... (I automate things in web pages for a living, and I only use tools like Firebug and LWP)

__a 13y ago

Calling ASCII a primary source of inefficiency that needs to be "fixed", in the presence of so much rubbish (advertising) being force fed to users by so many websites, is a red flag that this is not truly concerned with efficiency for users' benefit. It may be more concerned with efficiency for those serving up the rubbish. There are other sources of inefficiency that one could argue are much larger sources of inefficiency for end users. Unwanted advertising could be at the top of the list. Resolving domain names of ad servers that serve the user no intentionally requested content, day after day, might be another. True "efficiency" would be embodied by the user receiving only what she requests (the content), and nothing more. A question to ask might be: will a binary protocol make this easier or more difficult for users to achieve? In a vacuum, absent any surrounding context, binary does trump ASCII for efficiency in transmitting and receiving information over a wire. No contest. But in the context of the world wide web, which is a visual medium to be read by humans, moving to a binary protocol does not guarantee that the web will become more "efficient" for end users. If I am an advertiser and can more efficiently insert rubbish into the content the end user is seeking, does that make the web more "efficient"? And who is it that is responsible for 95% of the revenue of the company that designed SPDY/HTTP 2.0? End users? Guess again. The answer is: advertisers.