[
https://issues.apache.org/jira/browse/SOLR-11266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889152#comment-16889152
]
Gus Heck commented on SOLR-11266:
---------------------------------
{quote}More than someone trying to write a context-free Solr client I'd say ;)
{quote}
You mean like jquery? with it's default intelligent guess setting?
{panel:title= dataType (default: Intelligent Guess (xml, json, script, or
html))}
Type: [String|http://api.jquery.com/Types/#String]
The type of data that you're expecting back from the server. If none is
specified, jQuery will try to infer it based on the MIME type of the response
(an XML MIME type will yield XML, in 1.4 JSON will yield a JavaScript object,
in 1.4 script will execute the script, and anything else will be returned as a
string).
{panel}
Seen here in dev console on current solr home page with a collection named foo:
{code:java}
$.ajax("/solr/foo/query?q=*:*").done(function(data) {console.log(typeof data)});
string
{code}
Sure you can specify the dataType as json (i.e. hardcode the expected type, the
most common solution)... but by default you get a string, and so first contact
with solr for most jquery ui programmers is to hit an error and discover that
the jquery defaults don't work...
{quote}(but it's not incorrect to have json formatted text in a plain text HTTP
response, and I disagree that this issue should be categorized as a bug.)
Although one can argue that application/json is *more* appropriate given that
it's more specific.
{quote}
absolutely true from the HTTP spec perspective, anything that can handle
text/plain will not break when receiving application/json, but not true from a
JSON perspective where RFC 4627 and 7159 do state that the correct media type
is application/json. So one can say correctly that we serve valid text/plain.
One can't say that we are serving valid JSON, because we haven't served it with
the correct media type.
It is true that the error we are making is so common (see also: text/json
text/x-json, etc) that there are easy workarounds built into many libraries.
> V2 API returning wrong content-type
> -----------------------------------
>
> Key: SOLR-11266
> URL: https://issues.apache.org/jira/browse/SOLR-11266
> Project: Solr
> Issue Type: Bug
> Components: v2 API
> Reporter: Ishan Chattopadhyaya
> Priority: Major
> Attachments: SOLR-11266.patch
>
>
> The content-type of the returned value is wrong in many places. It should
> return "application/json", but instead returns "application/text-plan".
> Here's an example:
> {code}
> [ishan@t430 ~] $ curl -v
> "http://localhost:8983/api/collections/products/select?q=*:*&rows=0";
> * Trying 127.0.0.1...
> * TCP_NODELAY set
> * Connected to localhost (127.0.0.1) port 8983 (#0)
> > GET /api/collections/products/select?q=*:*&rows=0 HTTP/1.1
> > Host: localhost:8983
> > User-Agent: curl/7.51.0
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Content-Type: text/plain;charset=utf-8
> < Content-Length: 184
> <
> {
> "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":1,
> "params":{
> "q":"*:*",
> "rows":"0"}},
> "response":{"numFound":260,"start":0,"docs":[]
> }}
> * Curl_http_done: called premature == 0
> * Connection #0 to host localhost left intact
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
