As in all things web, this is related to user agents (specifically IE) having a horrendous misunderstanding of what the Accept header is for. If you google "Accept header IE" you'll see a long list of hits about its particular brand of gnarly.
Notice the obvious missing entries like text/html, text/plain etc etc. By default, IE is saying "I prefer all these other things to HTML."
The second follow on here is that if a resource provides two content-types for the same resource, and an accept header matches both with equal priority, then the server gets to decide which representation to return. The first example the author gives is technically correct in this regard. His probing shows that Netflix is being a bit naughty, but not without just cause.
Basically, they're making the assumption, "Anyone that asks for JSON really wants it." which does violate the spec, but given the long history of user agents that have historically broken this spec I can only say that its not a question of whether the spec is broken, but how it's broken.
For instance, the spec mentions in passing that given an Accept header of:
text/html, text/*
That text/html should be preferred to text/plain even though both would end up with a quality of 1.0. Although there's no actual algorithm defined for dealing with this situation. The entire decision tree is left implicit based on the examples provided.
Anyway, getting in a huff that your browser extension breaks a website that tries to cater to developers while providing reasonable content to people that still use IE is a bit awkward. Especially if you've written a book on HTTP and haven't realized that maybe there's a certain amount of spec breakage to deal with weirdo user agents.
IE is not preferring anything in your example. The default quality is 1.0, and since no quality is indicated for any type, they all share the highest preference.
Although IE's Accept header is technically useless, it's more likely to be a response to developers incorrectly parsing Accept than the other way around. This post is about sites using primitive string matching to parse Accept, and it's not unreasonable to imagine that this problem is not new.
You also claim that the spec leaves the resolution between text/html and text/* ambiguous, but it clearly states why text/html has precedence:
"If more than one media range applies to a given type, the most specific reference has precedence."
Lastly, I only get in a huff when people use illogic, especially ad hominems, to prop up a poor argument. In fact, I've written about this, too:
> That text/html should be preferred to text/plain even though both would end up with a quality of 1.0. Although there's no actual algorithm defined for dealing with this situation. The entire decision tree is left implicit based on the examples provided.
It does a bit more than show example in passing, it specifies the following:
> Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies to a given type, the most specific reference has precedence.
And indicates how precedence works: accept extensions > "full" mime > type/wildcard > wildcard.
The only situation which is not defined out is a type/wildcard with an extension.
This tie-breaker happens after quality-based precedence resolution.
(full agreement on Accept headers of browsers, they're completely bonkers)
An example IE Accept header might look like such:
Notice the obvious missing entries like text/html, text/plain etc etc. By default, IE is saying "I prefer all these other things to HTML."The second follow on here is that if a resource provides two content-types for the same resource, and an accept header matches both with equal priority, then the server gets to decide which representation to return. The first example the author gives is technically correct in this regard. His probing shows that Netflix is being a bit naughty, but not without just cause.
Basically, they're making the assumption, "Anyone that asks for JSON really wants it." which does violate the spec, but given the long history of user agents that have historically broken this spec I can only say that its not a question of whether the spec is broken, but how it's broken.
For instance, the spec mentions in passing that given an Accept header of:
That text/html should be preferred to text/plain even though both would end up with a quality of 1.0. Although there's no actual algorithm defined for dealing with this situation. The entire decision tree is left implicit based on the examples provided.Anyway, getting in a huff that your browser extension breaks a website that tries to cater to developers while providing reasonable content to people that still use IE is a bit awkward. Especially if you've written a book on HTTP and haven't realized that maybe there's a certain amount of spec breakage to deal with weirdo user agents.