Skip to main content

Bug Tracker

Side navigation

#12250 closed bug (invalid)

Opened August 10, 2012 04:25PM UTC

Closed August 17, 2012 07:07AM UTC

Accept header for dataType: json

Reported by: bengeorge@gmail.com Owned by:
Priority: low Milestone: 1.next
Component: ajax Version: 1.8.0
Keywords: Cc:
Blocked by: Blocking:
Description

When using jQuery.ajax with the dataType of json the following accepts header is produced: "application/json, text/javascript, */*; q=0.01".

This indicates to the server that application/json, text/javascript and */* have the same preference.

More likely you want something like 'application/json; q=0.9, text/javascript; 0.8, */*;q= 0.7'. This will make json as the prefered media type when using the 'json' dataType.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Peace out!

Attachments (0)
Change History (9)

Changed August 16, 2012 02:26PM UTC by jaubourg comment:1

component: unfiledajax
milestone: None1.next
priority: undecidedlow
status: newopen

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

Changed August 16, 2012 02:54PM UTC by anonymous comment:2

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.

Changed August 16, 2012 03:36PM UTC by jaubourg comment:3

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?

Changed August 16, 2012 03:38PM UTC by dmethvin comment:4

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.

Changed August 16, 2012 06:52PM UTC by anonymous comment:5

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.

Changed August 16, 2012 07:11PM UTC by anonymous comment:6

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.

Changed August 16, 2012 10:48PM UTC by jaubourg comment:7

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?

Changed August 17, 2012 05:32AM UTC by anonymous comment:8

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

Apologies!!

Changed August 17, 2012 07:07AM UTC by jaubourg comment:9

resolution: → invalid
status: openclosed