2012-06-08 14 views
6

¿Es posible configurar el envío de un encabezado de respuesta HTTP personalizado desde el archivo solrconfig.xml? Estoy pensando que podría ser posible agregar alguna configuración a la sección <requestDispatcher> ya que controla los encabezados de almacenamiento en caché.Apache Solr: configuración de cabeceras de respuesta HTTP de solrconfig.xml Para CORS

Estoy seguro de que esto es posible en la configuración del contenedor de servlets (Jetty, Tomcat, etc.), pero me gustaría hacerlo desde los archivos de configuración de Solr si es posible.

Si esto hace la diferencia, estoy intentando establecer un encabezado Access-Control-Allow-Origin para solicitudes CORS AJAX de un host diferente.

Respuesta

7

Puede usar JSONP en su lugar. Vea este enlace para ver un ejemplo

+0

Gracias por el enlace. Definitivamente consideraré esto para mi recuperación, pero me gustaría obtener CORS real trabajando si es posible. –

+0

Lo siento, tomó tanto tiempo darle crédito. Finalmente implementé la solución y terminé yendo con JSONP ya que el soporte para esto está integrado en Solr. –

1

La forma más fácil será escribir encargo javax.servlet.Filter y añadir la cabecera Access-Control-Allow-Origin allí. Para el código que maneja el procesamiento HTTP, vea la clase org.apache.solr.servlet.SolrDispatchFilter.

ES LA FORMA MÁS FÁCIL PARA PROCEDER. Si miras el doFilter en SolrDispatchFilter, la única manipulación con encabezados HTTP es almacenarlos en caché y no hay lugar para tocarlos de alguna manera.

0

soldar frontal con apache, y confía en devolver el encabezado. Por ejemplo,

Header set X-Server-Name "abc0.com" 
0

Encontré this útil. Debería agregar un par de embarcaderos y cambio webdefault.xml para habilitar CORS.

reproduzco el texto aquí:


En el proyecto de ejemplo Solr cuando se inicia hasta llamando a la línea siguiente:

java-jar empezar

Usted está comenzando una Jetty server en su máquina local que servirá los resultados del solr. Este servidor no puede hacer CORS (Intercambio de recursos de origen cruzado). Lo que significa que si intenta hacer una llamada AJAX desde una página web de un origen diferente al servidor en sí, se le denegaría una respuesta.

Para solucionar esto, primero necesita obtener los archivos adecuados para permitir el intercambio de recursos entre dominios.

que utilizó la siguiente jar: http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-servlets/8.1.10.v20130312/

pero puede que necesite para obtener la versión que sea adecuado para su versión de amarre: http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-servlets/

Puede averiguar qué versión del embarcadero se está ejecutando con su ejemplo Solr yendo: java-jar empezar --version

y verá un vertedero de la siguiente manera: C: \ Users \ nombre de usuario \ Desktop \ Solr-4.8.0 \ ejemplo> java-jar start.jar --version Opciones activas: [predeterminado, *] Versión Información sobre 18 entradas en el classpath. Nota: el orden presentado aquí es cómo aparecerían en el classpath. cambios en la opción de línea de comando OPCIONES = [opción, opción, ...] se reflejarán en re.

0:    (dir) | ${jetty.home}\resources 
1:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-xml-8.1.10.v20130312.jar 
2: 3.0.0.v201112011016 | ${jetty.home}\lib\servlet-api-3.0.jar 
3:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-http-8.1.10.v20130312.jar 
4:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-continuation-8.1.10.v20130312.jar 
5:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-server-8.1.10.v20130312.jar 
6:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-security-8.1.10.v20130312.jar 
7:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-servlet-8.1.10.v20130312.jar 
8:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-webapp-8.1.10.v20130312.jar 
9:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-deploy-8.1.10.v20130312.jar 
10:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-servlets-8.1.10.v20130312.jar 
11:    1.7.6 | ${jetty.home}\lib\ext\jcl-over-slf4j-1.7.6.jar 
12:    1.7.6 | ${jetty.home}\lib\ext\jul-to-slf4j-1.7.6.jar 
13:    1.2.16 | ${jetty.home}\lib\ext\log4j-1.2.16.jar 
14:    1.7.6 | ${jetty.home}\lib\ext\slf4j-api-1.7.6.jar 
15:    1.7.6 | ${jetty.home}\lib\ext\slf4j-log4j12-1.7.6.jar 
16:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-util-8.1.10.v20130312.jar 
17:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-io-8.1.10.v20130312.jar 

Busque la línea que dice $ {} jetty.home \ lib \ embarcadero-servidor (en el vertedero por encima de su línea 5) y usted debería ser capaz de ver su versión.

También querrá obtener el "amarre-util" para su versión embarcadero también: http://mvnrepository.com/artifact/org.mortbay.jetty/jetty-util

usted debería ser capaz de encontrar su versión de allí. Utilicé jetty-util-8.1.10.v20130312.jar para el mío.

Ahora tome tanto los archivos servlet.jar y util.jar que ha descargado y colocarlo en la carpeta siguiente: Solr-4.8.0 \ ejemplo \ lib

para su versión puede ser diferente, pero lo quiero en la carpeta lib bajo el directorio de ejemplo.

Por último, para permitir que estos cambios surtan efecto, desea abrir Solr-4.8.0 \ ejemplo \ etc \ webdefault.xml

y añadir las siguientes líneas antes de </web-app>:

<filter> 
     <filter-name>cross-origin</filter-name> 
     <filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class> 
    </filter> 
    <filter-mapping> 
     <filter-name>cross-origin</filter-name> 
     <url-pattern>/*</url-pattern> 
    </filter-mapping> 

Ahora reinicie su servidor y debería tener CORS habilitado.

Notas: Si comienza a ser elegante y tiene varias aplicaciones web ejecutándose en el servidor de embarcaciones de ejemplo Solr, esto afectará a todas esas aplicaciones web. Tenga en cuenta que ha configurado el patrón de URL para reconocer cualquier dominio que sea peligroso para una configuración de producción. Esto es solo para pruebas locales.

También traté de cambiar el archivo web.xml en la carpeta webapps para que estos cambios permanecieran locales pero después de horas de tratar de que funcionara, me di por vencido y descubrí que ponerlo en la webdefault global funcionaba .

Cuestiones relacionadas