
Unacceptable Browser HTTP Accept Headers (Yes, You Safari and Internet Explorer) - KrisJordan
http://www.newmediacampaigns.com/page/browser-rest-http-accept-headers
======
ajross
Being completely serious here: who cares? The Accept: header has never been
useful. It's an overdesigned disaster of complexity, trying to handle in the
client something that is trivially doable at the server level.

Ignoring for the moment that there are "good" and "bad" ways to specify it.
Has there ever been _worthwhile_ application for this thing? In what way would
a browser that simply left it off have trouble?

~~~
defen
Perhaps you are thinking of the case where HTTP is used as a simple file-
transfer protocol - where there is a 1-1 mapping between URLs and files on the
server. However if you think of things at a higher level, where URLs map to
generic "resources", it is plausible that a single resource could have
multiple representations. Think of the Twitter API - a tweet can be
represented in XML or JSON. This is the principal behind REST (granted,
Twitter does not actually follow the HTTP standard, but you get the idea).

That said, for the overwhelming use-case of HTTP (web browsing), REST and the
Accept header are probably overkill.

~~~
ajross
I understand what it's for; I'm dubious that it's actually used. By your own
example, twitter doesn't actually do this. Does anyone, to your knowledge?
This header has been there for 12+ years. If no one's used it so far, tell me
again why I should care that some browser sets a bad value?

~~~
trezor
With Apache you can set the server to provide specific resources that the
browser supports.

For instance serving regular GIFs or whatever to MSIE, and SVGs or transparent
PNGs to Firefox. You can also use it to serve proper XHTML to all browsers
except MSIE.

These are real world use cases where I know people use.

~~~
ajross
That's actually exactly the wrong thing to do. If you're serving content based
on the browser, you want to be inspecting User-Agent, not Accept. And yes,
people do that all the time. But they never do it based on what the browser
claims to support; they do it based on what the client actually claims to be,
based on what they have tested against real software.

------
kd5bjo
When I was writing some of our internal HTTP apis, I came up with a reasonable
compromise -- honor the Accept header, but treat any file extension as a
limitation of it. .../foo could return any supported type, but .../foo.html
is, by definition, the HTML version of the resource (and will return a 406 Not
Acceptable if the Accept header doesn't include text/html, text/(star), or
(star)/(star) ).

EDIT: the asterisks in my MIME type notations were interpreted as markup.

------
blasdel
Firefox totally fucks up MIME types in a different way -- since version 2.0.1X
it is extraordinarily anal about 'respecting' the Content-Type that the server
returns. It basically means that if you want your text to be displayed in the
browser, you have to declare it text/plain.

Oh, your webserver helpfully sniffs the extension in the filesystem, and
serves up some example C code as 'text/x-csrc'? There's _no way_ Firefox could
ever possibly display that! The default should obviously be to 'open with' an
external viewer, even if that's _less_ or _vim_.

It's not very useful to open a downloaded document using a curses program,
especially when stdout is not a tty!

This behavior is not configurable or reversible. I found and hacked together
an ancient extension that adds 'View in Firefox' to the 'open with' list, but
it's not on addons.mozilla.org

~~~
ars
Wow. I never expected I would see someone complain about this.

Firefox is following the mime types _exactly_ the correct way.

Compare to the disaster of IE which sometimes looks at the file extension to
decide how to display the document - that caused me huge problems way back.

Yes, a view as text option would be nice, but firefox is doing exactly the
right thing by listening to the mime type.

If I get text/csv I don't want it showing in the browser, I want it to launch
it externally. If firefox gets text/x-csrc it checks the /etc/mailcap, and
does what it's told. It has no way to guess that you prefer to view it in the
browser - the server said: it's a C file, and firefox listens.

How would you program it? How is it supposed to know that text/x-csrc should
show in the browser, while text/csv is an external program? Both are listed in
mailcap.

However, like I said, an option "View as Text" in the download box would be
nice.

~~~
brodie
I'd prefer that it display all text/* content in the browser. If I want to
save it, then I'll save it.

~~~
windsurfer
Well then tell Firefox that. You can configure what it's behaviour is in the
preferences pane. The defaults are _perfect_ , it's your _preference_ that's
different from the standard. Which is why they put it in _Preferences_.

~~~
blasdel
"Display it in the browser" is not an option. Have you even looked?

The preference pane does not let you create new lines -- the only way to add
rules as a user is to encounter the Content-Type in the wild.

~~~
arantius
Not stock. But you can get it:

<https://addons.mozilla.org/en-US/firefox/addon/8207>

~~~
blasdel
Awesome! I was using a hacked-on 3-year-old version of that, as it was never
on AMO -- I even searched for it when commenting in this thread.

Awesome little gem: I went to Tools > Add-ons > Extensions > Find updates --
and it found and downloaded the new AMO version of my hacked local copy!

------
aston
Maybe there's some utility in the Accept header as a signal of the
capabilities of the browser/client. There's a nice discussion [1] on using the
Accept header to suss out whether to send the 'correct' but generally less-
usable 'application/json' mime type or just send the blatantly wrong but
working 'text/javascript' instead. Given a client with the capability, you
should go ahead and send it the way the client prefers, right?

[1] <http://simonwillison.net/2009/Feb/6/json/>

