[ https://issues.apache.org/jira/browse/SOLR-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15014290#comment-15014290 ]
Garth Grimm edited comment on SOLR-5971 at 11/19/15 8:23 PM: ------------------------------------------------------------- Another customer with the same issue (running 5.3). When the query is initially directed to a node with a core from the collection things work correctly. When directed to a node without a core from the collection, an error is throwing showing the URL parsing error from one of the nodes WITH the proper core. So a query like this would work (node has the core on it): http://machine1:8983/solr/someCollection/select?q=id:something^2 But this query (node doesn't have the core on it): http://machine3:8983/solr/someCollection/select?q=id:something^2 Will yield an error message like: Illegal character in query at index XX: http://machine1:8983/solr/someCollection/select?q=id:something^2 So it appears that the proxy code on machine3 is mangling the URL that is being passed to machine1? Also, by URL-encoding the ^ character in the query, the issue can be avoided. So this query would work fine against any node: http://machine3:8983/solr/someCollection/select?q=id:something%5E2 was (Author: gdgrimm): Another customer with the same issue. When the query is initially directed to a node with a core from the collection things work correctly. When directed to a node without a core from the collection, an error is throwing showing the URL parsing error from one of the nodes WITH the proper core. So a query like this would work (node has the core on it): http://machine1:8983/solr/someCollection/select?q=id:something^2 But this query (node doesn't have the core on it): http://machine3:8983/solr/someCollection/select?q=id:something^2 Will yield an error message like: Illegal character in query at index XX: http://machine1:8983/solr/someCollection/select?q=id:something^2 So it appears that the proxy code on machine3 is mangling the URL that is being passed to machine1? Also, by URL-encoding the ^ character in the query, the issue can be avoided. So this query would work fine against any node: http://machine3:8983/solr/someCollection/select?q=id:something%5E2 > 'Illegal character in query' when proxying request > -------------------------------------------------- > > Key: SOLR-5971 > URL: https://issues.apache.org/jira/browse/SOLR-5971 > Project: Solr > Issue Type: Bug > Components: SolrCloud > Affects Versions: 4.7.1 > Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build > 1.6.0_26-b03) > Reporter: Eric Bus > Labels: characters, exception, invalid, proxy, query, solrcloud > > My cluster contains 3 Solr instances. I have a collection consisting of one > shard with 2 replica's. So one node in the cluster does not have a replicate > of the shard. > The following query works when I query one of the two replica nodes: > http://X.X.X.X:8080/solr/collection/select/?facet=true&facet.field={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month&facet=true&q=*:* > But when I query the node without the replica, I get; > {msg=Illegal character in query at index 78: > http://X.X.X.X:8080/solr/collection/select/?facet=true&facet.field={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month&facet=true&q=*:*,trace=java.lang.IllegalArgumentException > at java.net.URI.create(URI.java:842) > at org.apache.http.client.methods.HttpGet.<init>(HttpGet.java:69) > at > org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) > at org.eclipse.jetty.server.Server.handle(Server.java:368) > at > org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) > at > org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) > at > org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942) > at > org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640) > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) > at > org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) > at > org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) > at java.lang.Thread.run(Thread.java:662) > Without the facet.field attribute, it works fine on all the nodes. > Is this some kind of double escaping when proxying the request? -- 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