2011-03-08 16 views
5

Nota: Se realizaron algunas actualizaciones según la información nueva. Las ideas antiguas se agregaron como comentarios a continuación. Nota: Hizo algunas actualizaciones (nuevamente) basadas en nueva información. Las ideas antiguas se agregaron como comentarios a continuación (nuevamente).La replicación de CouchDB no funciona correctamente detrás de un proxy

Estamos ejecutando dos instancias de CouchDB en equipos separados detrás de proxies inversos Apache. Al intentar replicar entre las dos instancias:

curl -X POST http://user:[email protected]/couchdb/_replicate -d '{ "source": "db1", "target": "http://user:[email protected]/couchdb/db1" }' --header "Content-Type: application/json" 

(que empezamos a usar curl para depurar el problema)

recibimos un error similar al siguiente:

{"error":"case_clause","reason":"{error,\n {{bad_return_value,\n   {invalid_json,\n    <<\"<!DOCTYPE HTML PUBLIC \\\"-//IETF//DTD HTML 2.0//EN\\\">\\n<html><head>\\n<title>404 Not Found</title>\\n</head><body>\\n<h1>Not Found</h1>\\n<p>The requested URL /couchdb/db1/_local/01e935dcd2193b87af34c9b449ae2e20 was not found on this server.</p>\\n<hr>\\n<address>Apache/2.2.3 (Red Hat) Server at 10.1.100.59 Port 80</address>\\n</body></html>\\n\">>}},\n  {child,undefined,\"01e935dcd2193b87af34c9b449ae2e20\",\n   {gen_server,start_link,\n    [couch_rep,\n    [\"01e935dcd2193b87af34c9b449ae2e20\",\n    {[{<<\"source\">>,<<\"db1\">>},\n     {<<\"target\">>,\n     <<\"http://user:[email protected]/couchdb/db1\">>}]},\n    {user_ctx,<<\"user\">>,\n     [<<\"_admin\">>],\n     <<\"{couch_httpd_auth, default_authentication_handler}\">>}],\n    []]},\n   temporary,1,worker,\n   [couch_rep]}}}"} 

así que infórmate después de un nuevo aparece que apache devuelve este error sin intentar acceder a CouchDB (de acuerdo con los archivos de registro). Para ser claros cuando se alimenta el siguiente URL

/couchdb/db1/_local/01e935dcd2193b87af34c9b449ae2e20 

Apache pasa la solicitud al CouchDB y devuelve error de CouchDB 404. Por otro lado, cuando la replicación se produce en realidad la URL que se pasa es

/couchdb/db1/_local%2F01e935dcd2193b87af34c9b449ae2e20 

la que determina Apache es un documento que falta y devuelve su propio error 404 sin cada vez que pasa la solicitud al CouchDB. Esto al menos me da algunas pistas nuevas, pero igual podría utilizar la ayuda si alguien tiene una respuesta inmediata.

+0

El problema parece tener algo que ver con el HTML devuelto por el servidor remoto (sucede como una fuente o un destino). La reescritura parece ser 'automágica'. La página no coincide con el 404 presentado en los documentos de error de Apache (que no están activos de todos modos). Parece que hay propiedades similares en la biblioteca INETS basada en Erlang, pero no son exactamente iguales y mis intentos de editar las secciones apropiadas no tuvieron resultados que pudiera decir. ¿Alguna idea? – Wesley

+0

Verifiqué los archivos de registro y, al contrario del mensaje de retorno, lo que realmente envía el sofá es "/ couchdb/db1/_local% 2F01e935dcd2193b87af34c9b449ae2e20" (barra oblicua) que da como resultado el mismo error acerca de que se devuelve HTML mientras la URL con barra inclinada devuelve el espera error JSON. Este problema no ocurre en ninguna situación sin el proxy. Esto implica que el problema está en el proxy, pero el manejo del ErrorDocument del proxy está desactivado y ninguno de los archivos enumerados coincide de todos modos. ¿Alguien tiene más sugerencias? – Wesley

+0

En este punto, como está depurando/configurando un proxy inverso httpd de Apache, puede intentar preguntar sobre el error del servidor. Me imagino que esas personas comen proxies inversas para el desayuno. Actualicé mi respuesta para hablar sobre rutas y códigos de escape un poco. – JasonSmith

Respuesta

1

De la documentación oficial ...

Tenga en cuenta que los proxies HTTPS están en teoría apoyada, pero no funcionan en 1.0.1. Esto es porque 1.0.1 se envía con la versión 1.5.5 de ibrowse. La versión CouchDB en trunk (desde donde se basará 1.1) se envía con ibrowse versión 1.6.2. Este último intruso contiene correcciones para proxies HTTPS.

¿Puedes ver qué versión de ibrowse está involucrado? Tal vez actualizar ese ver?

+0

Observado pero no relevante. El error ocurre al acceder a través de HTTP. A propósito, estoy usando la última versión de CouchDB, que incluye actualizaciones de comportamientos de proxy. – Wesley

1

Otra idea que tengo es con respecto a los certificados SSL. Si no tiene ninguno, y sé que no :), entonces técnicamente está haciendo SSL incorrecto. En Java sabemos que hay formas de evitar esto, pero tal vez intentemos poner los certs adecuados, ya que todo lo relacionado con SSL implica certs.

2

La fuente CouchDB (localhost) le está diciendo que la URL remota no era válida. En lugar de una respuesta CouchDB, la fuente está recibiendo la respuesta del proxy httpd de Apache respuesta de archivo no encontrado.

Lamentablemente, es posible que tenga que resolver algunos problemas de proxy inverso. Mi primera suposición es el encabezado Host que la fuente está enviando al destino. ¿Quizás es diferente de cuando te conectas directamente desde una tercera ubicación?

Por último, creo que probablemente sabe esto, pero el camino

/couchdb/db1/_local%2F01e935dcd2193b87af34c9b449ae2e20 

Es no una ruta estándar CouchDB. Para cuando CouchDB vea una solicitud, debe tener el /couchdb desprotegido, por lo que la consulta es para un documento llamado _local%2f... en la base de datos llamada db1.

Por cierto, es muy importante no dejar que el proxy modifique las rutas antes de que golpeen el sofá. En particular, si envía %2f, entonces CouchDB debe recibir mejor %2f y si envía /, entonces CouchDB debe recibir mejor /.

+0

De hecho, verifiqué la respuesta de archivo no encontrado del servidor httpd y no está activo y no coincide. ¿Hay un conjunto diferente de archivos/configuraciones de respuesta para el proxy (y tienes alguna idea de dónde podrían estar)? Además, verificaré el encabezado HOST; Gracias por la sugerencia. – Wesley

+0

Bueno, de todos modos eso definitivamente es ** no ** un CouchDB 404. Si googleas esa frase, los resultados están llenos de mensajes httpd de Apache. Lo sé, es muy frustrante. Otra cosa que hacer es observar los registros de CouchDB de destino y sus registros de proxy simultáneamente durante una replicación. – JasonSmith

+0

De acuerdo, la reescritura de errores está casi definitivamente en el proxy, pero no tiene nada que ver con el encabezado HOST. Actualicé la pregunta principal con más detalles. ¿Alguna idea nueva? No entiendo por qué reescribiría el error para uno pero no para el otro. – Wesley

Cuestiones relacionadas