Opened 10 years ago
Closed 10 years ago
#12250 closed bug (invalid)
Accept header for dataType: json
Reported by: | 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 10 years ago by
Component: | unfiled → ajax |
---|---|
Milestone: | None → 1.next |
Priority: | undecided → low |
Status: | new → open |
comment:2 Changed 10 years ago by
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 follow-up: 6 Changed 10 years ago by
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 follow-up: 5 Changed 10 years ago by
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 Changed 10 years ago by
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 follow-up: 7 Changed 10 years ago by
Replying to jaubourg:
It seems to me that
json
andjavascript
should be mutually exclusive, hence my struggle. I don't see what a server-side script delivering bothjson
ANDjavascript
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 givenjson
is a subset ofjavascript
and thatjavascript
that is notjson
will be rejected by thejson
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
andjsonp
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 thejsonp
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 Changed 10 years ago by
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:9 Changed 10 years ago by
Resolution: | → invalid |
---|---|
Status: | open → closed |
Sounds reasonable, but I'm still struggling with the actual practical gain.