[
https://issues.apache.org/jira/browse/SOLR-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14254819#comment-14254819
]
Charles Reitzel edited comment on SOLR-6369 at 12/20/14 3:39 PM:
-----------------------------------------------------------------
Per RFC 7159, "The names within an object SHOULD be unique." This is SHOULD
in the RFC sense, which means you should have a really good reason for not
doing it. This is why a majority of JSON implementations (All javascript
implementations, JAXB, Jackson, Gson, XStream, etc.) will either barf or
silently drop all but one of the values.
Also, as per the clarification above, this behavior is found in most (all?)
solr operations, not just ping. Any default parameters (not just wt)
overridden on the request appear duplicated in the response. Try this with a
request handler configured with a facet field. If a different facet field is
presented with the request, you get duplicate facets in the output. Not just
duplicated params in the response header. So there is something deeper going
on that needs fixing.
http://tools.ietf.org/html/rfc7159#section-4
was (Author: creitzel):
Per RFC 7159, "The names within an object SHOULD be unique." This is SHOULD
in the RFC sense, which means you should have a really good reason for not
doing it. Not just because you don't feel like it. This is why a majority of
JSON implementations (All javascript implementations, JAXB, Jackson, Gson,
XStream, etc.) will either barf or silently eat all but one of the values.
Also, as per the clarification above, this behavior is found in most (all?)
solr operations, not just ping. Any default parameters (not just wt)
overridden on the request appear duplicated in the response. Try this with a
request handler configured with a facet field. If a different facet field is
presented with the request, you get duplicate facets in the output. Not just
duplicated params in the response header. So there is something deeper going
on that needs fixing.
http://tools.ietf.org/html/rfc7159#section-4
> duplicate json key "echoParams" should be removed in ping-response
> ------------------------------------------------------------------
>
> Key: SOLR-6369
> URL: https://issues.apache.org/jira/browse/SOLR-6369
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.9
> Environment: testing on ubuntu 14.04
> version: 4.9.0 1604085 - rmuir - 2014-06-20 06:34:03
> Reporter: Marc Portier
> Priority: Trivial
>
> Apparently the /admin/ping handler will duplicate the echoParams key in the
> json-response.
> $ curl -s http://localhost:8983/solr/test-node-client/admin/ping?wt=json
> {"responseHeader":{"status":0,"QTime":2,"params":{"df":"text","echoParams":"all","rows":"10","echoParams":"all","wt":"json","q":"solrpingquery","distrib":"false"}},"status":"OK"}
> Having "echoParams":"all" twice in that response doesn't really make sense?
> Strictly speaking this is allowed in the json spec, so it is not a violation
> in principle
> http://stackoverflow.com/questions/21832701/does-json-syntax-allow-duplicate-keys-in-an-object
> However there are some json-parse implementations out there that want to map
> this into hashtables and are not silently overwriting the key with the last
> seen value, but are throwing errors in the process.
> To those a cleanup of the json response would make life somewhat easier.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
