> while i agree that you don't wnat to expose your end users > directly to > Solr (largely for security reasons) that doesn't mean you *must* > preprocess user entered strings before handing them to dismax > ... dismax's > whole goal is to make it posisble for apps to not have to worry about > sanitizing user inputed query strings.
I am using org.apache.solr.client.solrj.SolrQuery to preprocess user entered strings. And I am using dismax & facets: INFO: /select facet.limit=100&wt=xml&rows=100&start=0&facet=true&facet.mincount=1&q=Romeo% 2BJuliet&fl=id,item_name,category,price,url,host,country&qt=dismax&version=2 .2&facet.field=country&facet.field=host&facet.field=category&fq=category:"ar mani"&hl=true 0 1943 (catalina.out file of SOLR, http://www.tokenizer.org/armani/price.htm?q=Romeo%2bJuliet from production) As you can see, + sign is properly encoded in URL: %2B Unfortunately, DISMAX queries via CONSOLE do not support that. Fortunately, SOLRJ does. (Sorry for mistake in previous Email: it was direct SOLR request via admin console with "standard" handler.) =============== About https://issues.apache.org/jira/browse/SOLR-127 - We do not need this!!!!!!!!!!! Simply add request parameter http.header="If-Modified-Since: Tue, 05 Feb 2008 03:50:00 GMT", and let SOLR to respond via standard XML message "Not Modified", and avoid using 400/500/304!!! Let others manage "Reverse-Proxy" via PHP, HTTPD, Tomcat+Spring, etc.; SOLR can use exact "last-modified" timestamp from the index. I am going to comment SOLR-127... >
