Golang's network stack attempts to parse HTTP headers as UTF-8
Every time someone creates a new programming language, the world builds yet another pile of broken HTTP implementations--clients and servers--because everyone refuses to read the specifications, thinking &quot;none of this is hard&quot;. I remember dealing with some early Ruby web servers, 15 years ago, and was just shocked at how broken they were despite being used by everyone in production! In fact, there is a lot of nuance to HTTP, and as a civilization we seemed doomed to reliving the same mistakes over and over again every few years when the entire stack gets rewritten from scratch :&#x2F;.<p>So, I thereby was neither surprised to read that the Go HTTP server did this obviously-wrong thing... NOR was I particularly surprised to read the person complaining about it also didn&#x27;t seem to understand the correct behavior, either (though I do appreciate this is a bit &quot;unfair&quot;--I mean, it&#x27;s a tweet ;P--but I think still makes for an interesting point here) :&#x2F;. I have dealt with so many broken HTTP clients and servers over the years written by people who probably also never read the manual that came with their microwave because &quot;documentation is for idiots&quot; or whatever, that I have just become demoralized about it :(.<p>A few months ago, I was complaining about this, with a short list of stuff everyone tended to get wrong, and this HTTP header field encoding issue was on my shortlist :(.<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=24835617" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=24835617</a><p>&gt; FWIW, I have encountered tons of issues in peoples&#x27; &quot;this is easy, right?&quot; implementations of 100 Continue (including in some at-the-time major Ruby HTTP servers), non-ASCII encoding in HTTP headers (which has a ton of subtle rules, and just throwing around UTF-8 is <i>not</i> correct), and chunked Transfer-Encoding (though I can&#x27;t remember what was wrong); further, people often don&#x27;t even realize HTTP trailers <i>exist at all</i>, which is a bit infuriating :&#x2F;. (Note, though, that I am still <i>100%</i> on the side of the anti-HTTP&#x2F;2 camp in this thread.) The core problem is that somehow people think they can implement a spec without even, you know, <i>reading the spec</i>, which is so far past hubris as to have gone through incompetence into obvious negligence.<p>AFAIK, HTTP header fields are (in their generality) specified to be read as binary octets... but then are restricted to using ISO-8859-1 with the premise you are supposed to run them through a MIME parser? Like, some fields have strict formats, so you can&#x27;t do the full decoding until you know what you are working with--and so I would argue an HTTP library should give you the raw binary data (though decoding them through ISO-8859-1 first isn&#x27;t supposed to be &quot;wrong&quot;)--but for fields with user-displayable text (including HTTP status messages!) you can seriously embed &quot;Q&quot; encoded strings (of all things) if you want, a la RFC 2047. You can&#x27;t assume a field is restricted to ASCII too early in the parsing process.<p><a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc2047" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc2047</a>