The ups and downs of the HTTP header

A number of errors in this article makes me wary:<p>1. The &quot;request&quot; line in HTTP is not a header - it is the request, which can have associated headers. The headers are all “about” the request. The request itself is not a header, and does not follow the header syntax. (The historical reason for this is that the request line was defined in HTTP 0.9, which did not have headers.)<p>2. ISO-8859-1 is not “a crappy Windows character set”. It is an international standard specifically different from what Microsoft was using at the time (code page 437 was standard for MS-DOS in the US). Later, Windows switched to code page 1252, which is a copy of ISO-8859-1 except some extra glyphs in the bytes the ISO standard defined as control characters.

Why is the UA header so screwed up, aside from the historical issues with it? Isn&#x27;t it time that we replace it with something a bit more sane and structured? It seems the idea of detecting the browser vs detecting browser features goes back and forth. Sure, on the client side, where you have access to the DOM and the JavaScript runtime, it&#x27;s great to know whether you can use the placeholder attribute in a text input, but server-side you need to decide which video file to serve to the client, and this gets tricky.<p>Instead, why don&#x27;t we have something like this?:<p><pre><code> OS: Windows OS-Version: 8.1 Browser: Chrome Browser-Version: 18.5 </code></pre> (Not suggesting the format, just the type of data.)<p>That way we can ditch the stupid stuff such as &quot;like Gecko&quot; which means nothing, and focusing on actual useful things.

Well as part of a rant, I&#x27;ll point out two bizarro-world features of HTTP headers: Line folding and comments.<p>You can add arbitrary crlfs to any header, so long you start the next line with whitespace. Proper implementations need to properly treat every next line as part of the single header. Very annoying to implement (and other similar protocols implementations&#x27; do not all agree!), and no benefit. Unless you&#x27;re composing HTTP headers to read on a 80-column layout. And that kind of thing has no place in a computer protocol.<p>Comments. Seriously read this from the spec:<p><pre><code> Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing &quot;comment&quot; as part of their field value definition. In all other fields, parentheses are considered part of the field value. </code></pre> That&#x27;s even more bizarre. It further makes parsing need to know which header it is operating on. It just adds possibility for mis-implementation, security issues (confused deputy) and hurts performance. It&#x27;s only useful if you&#x27;re writing HTTP headers by hand and feel the need to comment them for ... I can&#x27;t think of a legit case.<p>&quot;Human readable&quot; computer protocols are debatable (parsing rules always seem to become more difficult, which is very bad), but &quot;human writable&quot; is just silly.

A bit of trivia why Opera is claiming to be 9.80: They used 10.00 in beta of Oepra 10 and found out that many site&#x27;s sniffers couldn&#x27;t process 2-digit version number. So with final release (and after that until the death of the browser) they used Opera&#x2F;9.80 and put the actual version elsewhere in the string.<p>That being said, people who sniff UA string to serve different content (or even block the user) should end up in hell. I&#x27;d start with Google.

Interesting article, but for the part about the User-Agent header, I really liked the history lesson by Aaron Andersen [1] from 2008.<p>[1] <a href="http://webaim.org/blog/user-agent-string-history/" rel="nofollow">http:&#x2F;&#x2F;webaim.org&#x2F;blog&#x2F;user-agent-string-history&#x2F;</a>

Can&#x27;t say I like the design of the page, but a good read nonetheless. Though after all those warnings, I expected it to be much longer. Is it really that long an article?

&gt; <i>Opera 12 then just gets weird on us. It says &quot;Generic English please, or U.S English, if not then uh... Arabic! If not then perhaps Catalan? If not then Danish, or if not that then Dutch. Ok perhaps Greek? Finnish?... Go home Opera, you&#x27;re drunk.</i><p>Most amusing part. Seriously, I can&#x27;t imagine why Opera sends all these languages in its request. Bizarre.

Slightly off topic, but this is the first post I&#x27;ve read on a Ghost-powered blog – I think it looks great.