Hi Alex, Thanks for confirming my finding. When it comes to Solr interfacing to a client, I agree completely. However, I was hoping to limit the noise at Solr and not have to add extra code to filter out the exceptions. Just wondering, wouldn't it be a cleaner RESTFUL interface if instead of reporting the stack trace in response, Solr would return an error code and a basic message pointing back to Solr log for details such as stack trace. I am curious, what use case would it serve where one would require the stack trace in response?
If there is interest, I could open an JIRA and come up with a patch. Regards, Koorosh -----Original Message----- From: Alexandre Rafalovitch [mailto:arafa...@gmail.com] Sent: Thursday, July 21, 2016 6:54 PM To: solr-user <solr-user@lucene.apache.org> Subject: Re: Any option to NOT return stack trace in Solr response? I don't think there is a flag. But the bigger question is whether you are exposing Solr directly to the client? You should not be. You should have a middleware client that talks to Solr and then generates web UI or whatever. If you give untrusted access to Solr, there are too many things that can be done, starting from deleting the whole index. It might be possible to have a smart proxy and expose Solr with heavily filtered valid URLs, then you would need to scrub response. That's all I can think of without hacking and reregistering with your own response handler (probably not that hard). Regards, Alex. ---- Newsletter and resources for Solr beginners and intermediates: http://www.solr-start.com/ On 22 July 2016 at 03:35, Koorosh Vakhshoori <koorosh.vakhsho...@synopsys.com> wrote: > Hi all, > Got a Solr 5.2.1 installation. I am getting following error response when > calling the TERMS component. Now the error is not the point, I know what is > going on in this instance. However, to address security concerns, I am trying > to have Solr truncate the stack trace in the response. Of course I would > still want Solr to log the error in its log file. What I was wondering, if > there is a flag or option I can set in solrconfig.xml globally or under TERMS > to omit the trace or just return ' java.lang.NullPointerException'? I have > looked at the source code and don't see anything relevant. However, I may > have missed something. Appreciated any suggestion and pointers. > > <response> > <lst name="responseHeader"> > <int name="status">500</int> > <int name="QTime">5</int> > </lst> > <lst name="error"> > <str name="trace"> > java.lang.NullPointerException at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(Sear > chHandler.java:322) at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandle > rBase.java:143) at > org.apache.solr.core.SolrCore.execute(SolrCore.java:2067) at > org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654) at > org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450) at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter > .java:227) at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter > .java:196) at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli > cationFilterChain.java:239) at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi > lterChain.java:206) at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli > cationFilterChain.java:239) at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi > lterChain.java:206) at > org.apache.catalina.filters.CorsFilter.handleNonCORS(CorsFilter.java:4 > 39) at > org.apache.catalina.filters.CorsFilter.doFilter(CorsFilter.java:178) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli > cationFilterChain.java:239) at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi > lterChain.java:206) at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa > lve.java:219) at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) > at > org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:526) > at > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078) > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:655) > at > org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at java.lang.Thread.run(Thread.java:745) > </str> > <int name="code">500</int> > </lst> > </response> > > Regards, > > Koorosh
