Hi, Trying to collect some community feedback on SOLR-16929 [0], which is trying to undo a change made in SOLR-15451. >From what I gather this change was made to allow auth related messages (which come as html) to be presented 'as a string' (basically skip decoding) to the user, but it accidentally covered the 400 errors (as shown below). introducing some bugs when the response is in javabin format. I am proposing to revert this 'present as a string' change for the 400s.
The part that I'm concerned about is the response format: Prior to SOLR-15451 it was a simple "one liner": java.util.concurrent.ExecutionException: java.io.IOException: --> http://127.0.0.1:65079/solr:sort param field can't be found: blah Post change it turned into a bigger chun: java.util.concurrent.ExecutionException: java.io.IOException: Query to '/streams_shard2_replica_n2/select?q=*:*&fl=a_s,a_i,a_f,blah&sort=blah+asc&distrib=false' failed due to: (400) { "responseHeader":{ "zkConnected":true, "status":400, "QTime":1 }, "error":{ "metadata":["error-class","org.apache.solr.common.SolrException","root-error-class","org.apache.solr.common.SolrException"], "msg":"sort param field can't be found: blah", "code":400 } } Now the actual question is: does this present any backwards compatibility issues? if anyone had upgraded and changed their code to parse the error and present something "nice" to the user, they are now presented with the requirement to change back to old style code. I would say there are no issues, but it doesn't hurt to ask before messing with this code (again). best, alex [0] https://issues.apache.org/jira/browse/SOLR-16929
