4 ms·

Unacceptable Browser HTTP Accept Headers (Yes, You Safari and Internet Explorer)

65 points by KrisJordan 17y ago

kd5bjo 17y ago
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.
ajross 17y ago
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 17y ago
  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 17y ago
    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?
    - defen 17y ago
      Well I don't know of anyone who actually does the right thing, but then again I'm not familiar with that many web services. I also don't necessarily think you should care that some browser sets a bad value - I guess the biggest issue is that since browsers are the most common HTTP clients, other HTTP implementations must conform to what browsers actually do, rather than the HTTP standard. This points to one of the "problems" with HTTP -- it's very easy to hack together your own solution to a problem instead of following the standard. This generally isn't a huge issue in any particular case, but it does increase the overall cognitive load of developers who deal with many APIs, make it harder to effectively utilize proxies and caching, and increase the amount of work that must be done by servers to accommodate the many clients out there, among other things. For example, rather than the desired MIME type of the response being specified by the URL itself, or by a query parameter, or by a post body parameter, or by the Accept header, it should just be in one place: the Accept header.
    - trezor 17y ago
      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 17y ago
        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.
    - holygoat 17y ago
      A bunch of APIs I've used, and many I've designed, use content negotiation with the Accept header. E.g., http://rdf.freebase.com/ http://rdf.freebase.com/
aston 17y ago
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/ http://simonwillison.net/2009/Feb/6/json/
blasdel 17y ago
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 17y ago
  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 17y ago
    I'd prefer that it display all text/* content in the browser. If I want to save it, then I'll save it.
    - windsurfer 17y ago
      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.

65 points by KrisJordan 17y ago

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.

ajross 17y ago

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 17y ago
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 17y ago
  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?
  - defen 17y ago
    Well I don't know of anyone who actually does the right thing, but then again I'm not familiar with that many web services. I also don't necessarily think you should care that some browser sets a bad value - I guess the biggest issue is that since browsers are the most common HTTP clients, other HTTP implementations must conform to what browsers actually do, rather than the HTTP standard. This points to one of the "problems" with HTTP -- it's very easy to hack together your own solution to a problem instead of following the standard. This generally isn't a huge issue in any particular case, but it does increase the overall cognitive load of developers who deal with many APIs, make it harder to effectively utilize proxies and caching, and increase the amount of work that must be done by servers to accommodate the many clients out there, among other things. For example, rather than the desired MIME type of the response being specified by the URL itself, or by a query parameter, or by a post body parameter, or by the Accept header, it should just be in one place: the Accept header.
  - trezor 17y ago
    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 17y ago
      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.
  - holygoat 17y ago
    A bunch of APIs I've used, and many I've designed, use content negotiation with the Accept header. E.g., http://rdf.freebase.com/ http://rdf.freebase.com/

aston 17y ago

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/ http://simonwillison.net/2009/Feb/6/json/

blasdel 17y ago

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 17y ago
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 17y ago
  I'd prefer that it display all text/* content in the browser. If I want to save it, then I'll save it.
  - windsurfer 17y ago
    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.