[
https://issues.apache.org/jira/browse/SOLR-11266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16886363#comment-16886363
]
Gus Heck commented on SOLR-11266:
---------------------------------
This behavior has been a peeve of mine... I've always found it irritating that
the content type is not appropriate for the content. This forces clients to be
written to make hard coded assumptions about content type (the most common
solution), do checks to find out what was requested on the request line (or
included in the POST data from the form), or to maintain state across the
request or do any one of a number of other non-standard things rather than
simply choose a parser based on content type. And that's if one has good
control over that communications code. Could be even more fun if the client
wants to use 3rd party code that refuses to ignore the header. I'm not of the
opinion that users looking at a response in a browser are our main target
audience. Javascript, Java, PHP and Python code probably constitute 1000x more
use cases than humans in browser window inspection, which is mostly an initial
development thing. If plain text is desired, that should be produced as the
result of an override. Looking back at that the referenced issue, the number
of folks rooting for application/json seemed way larger than those insisting on
text/plain
Standards are standards so that people can rely on them, and less inane
glue-code is needed for systems to talk to each other. I never like to see
software (be it open source or closed) half supporting or mutating or
"extending" standards. I'm very +1 that we target returning sane content types
that match the content actually returned for 9.x and provide a text/plain back
compatibility option for the request params and also as a global config
somewhere. It should not take special configuration to turn on "standards mode".
We should also be able to do Accept: negotiation and not require a url param
relating to content type at all, at which point a browser that didn't accept
json would likely fall back to text/plain...
> 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
>
> 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
