Bug Tracker

Opened 7 years ago

Closed 7 years ago

#12250 closed bug (invalid)

Accept header for dataType: json

Reported by: bengeorge@… 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!

Change History (9)

comment:1 Changed 7 years ago by jaubourg

Component: unfiledajax
Milestone: None1.next
Priority: undecidedlow
Status: newopen

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

comment:2 Changed 7 years ago by anonymous

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.

comment:3 Changed 7 years ago by 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?

comment:4 Changed 7 years ago by 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.

comment:5 in reply to:  4 Changed 7 years ago by anonymous

Replying to 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.

comment:6 in reply to:  3 ; Changed 7 years ago by anonymous

Replying to 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.

comment:7 in reply to:  6 Changed 7 years ago by jaubourg

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?

comment:8 Changed 7 years ago by anonymous

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

Apologies!!

comment:9 Changed 7 years ago by jaubourg

Resolution: invalid
Status: openclosed
Note: See TracTickets for help on using tickets.