> I'm saying that it's not too small. You still haven't mentioned anything about your use-case of needing several hundred(!?!?) different unique headers. 30 years of HTTP and so far there's been less than 100 defined.
That's not actually my use case. My objection is that you're basically advocating for running a code obfuscator on HTTP requests, which would make them far more painful to work with for very, very little gain.
>> So we'll all get to ask ourselves "what header is 3849, again?" way more than we ever should.
> Note that even those who have only a very vague idea of what HTTP is, know what a 404 is; and probably 403 too.
You're missing the point, numeric codes work there because almost no one defines new HTTP status codes. IIRC, there's maybe two dozen defined and most programmers could probably name only 4 or 5 off the top of their heads. People define new headers all the time.
Ints as identifiers have practically no human meaning at all. Very, very few will know what header 3000 is without looking it up, and because it's an int, when there's a naming collision the meanings will almost certainly be wildly different. It'll be a mess.
> Multiply that dozen bytes by however much traffic goes through the entire Internet... and it suddenly doesn't look small anymore.
Think of is this way: you're wasting bytes in your markup by using long names. Most JSON objects should never need more than 26 variables. How about we restrict variables to single-character strings? It'll save some bytes, and think about how much JSON is zipping around the internet. Ditto with our programs. Lets install a linter on your machine that will fail your builds if you use more than a 1-char variable name.
Also, it's well into the 21st century. Don't you think we should go back to two-digit years for most dates, because bytes?