Sounds reasonable, but I'm still struggling with the actual practical gain.

The actual practical gain is that using 'dataType: JSON' becomes useful to those who have resources available multiple media types.

For the time being, jQuery users have to explicitly set the accepts manually.

It seems to me that json and javascript should be mutually exclusive, hence my struggle. I don't see what a server-side script delivering both json AND javascript depending on a request header is actually trying to achieve. I can understand alternative video/image/music formats, but I can't wrap my head around this one, especially given json is a subset of javascript and that javascript that is not json will be rejected by the json parser (thankfully).

I'd need a *practical* example... as in an actual use-case. I do hope people are not using the same URL to deliver completely unrelated data according to the request's accept header.

The only use case I can think of is handling both json and jsonp responses with the same URL but, given the complete lack of access to request headers when using script tag injection and the fact you'd need to specify the jsonp callback in the URL parameters anyway, you'd much better off with inspecting the URL rather than relying on headers clients have no control over.

I suppose you encountered the problem. So what was it you were trying to do?

Don't most services that deliver multiple formats accept a URL parameter to specify it? Since so many of them are JSONP at the moment, there's no way to set a header in any case.

Replying to [comment:4 dmethvin]:

Don't most services that deliver multiple formats accept a URL parameter to specify it? Since so many of them are JSONP at the moment, there's no way to set a header in any case.

Yes but it doesn't make it correct :) Accept headers is by far a much preferred method to specifying the desired media type.

Replying to [comment:3 jaubourg]:

It seems to me that json and javascript should be mutually exclusive, hence my struggle. I don't see what a server-side script delivering both json AND javascript depending on a request header is actually trying to achieve. I can understand alternative video/image/music formats, but I can't wrap my head around this one, especially given json is a subset of javascript and that javascript that is not json will be rejected by the json parser (thankfully). I'd need a *practical* example... as in an actual use-case. I do hope people are not using the same URL to deliver completely unrelated data according to the request's accept header. The only use case I can think of is handling both json and jsonp responses with the same URL but, given the complete lack of access to request headers when using script tag injection and the fact you'd need to specify the jsonp callback in the URL parameters anyway, you'd much better off with inspecting the URL rather than relying on headers clients have no control over. I suppose you encountered the problem. So what was it you were trying to do?

Practical example: I have a resource /magazine/<id> with HTML and json being supported media types. HTML for the browser, and json to be consumed by another page (via jQuery) which dynamically loads magazine data. ie: a RESTfull 'architecture'.

If you use jQuery.ajax with dataType json the application server is within its rights to send back either HTML or json.

Again this is the generated accepts header: application/json, text/javascript, */*; q=0.01

Note the '*/*' part. X,Y,Z; q=0.01 means that X,Y,Z all have the same quality factor of 0.01 (degree of preference).

If you want backwards compatibility (with poorly configured application servers) which I'm sure you do: 'application/json; q=0.9, text/javascript; 0.8, */*;q= 0.7'

This gives preference to application/json, next text/javascript next everything else.

Note the '*/*' part. X,Y,Z; q=0.01 means that X,Y,Z all have the same quality factor of 0.01 (degree of preference).

That's not at all how the Accept header works. If the quality factor is not given for a mimetype, then it defaults to 1. So X, Y, Z;q=0.01 actually means X;q=1, Y;q=1, Z;q=0.01. So, in your example, this means that json will be the preferred format, not html. This will work as expected.

Only a highly non-standard server would understand the header differently (something we obviously cannot support).

So, the only thing we'll achieve with the proposed change is to give priority to json over javascript and I still can't find a practical use-case for this.

Did you actually encounter a problem with the Accept header we use today for json requests?

I miss read the spec, close the bug!!!

Apologies!!