mod_wsgi comportamiento inesperado en bookmarklet presentar o acción base de datos relacionada

Question

[actualiza a continuación]

Tengo un poco de un problema de implementación de un sitio en Apache con mod_wsgi con algunas funciones JavaScript bookmarklet; alfa sitio está en marcha y utilizable aquí: stemhub.org . El problema es que el bookmarklet (que es un botón de menú del navegador) somete a una página como

http://stemhub.org/submit/http://the-users-link.com/here

que luego devuelve un formulario para guardar metadatos sobre el enlace. La función de vista (un matraz / werkzeug aplicación) comprueba la base de datos para ver si el enlace ya se ha añadido, a continuación, devuelve el formulario con un ID de enlace, ya sea pre-existente o recién asignado, que supongo que podría desencadenar algún tipo de problema de tiempo. Muy extrañamente, cuando por primera vez de enviar el enlace, me sale la página http://stemhub.org/submit/http://the-users-link.com/here con un "no encontrado" Apache error, pero si me vuelva a cargar la página, consigo la forma como se pretende. Los registros de errores contienen mensajes sobre el roscado excepciones, pero lo hacen cuando los perfoms sitio como se espera, también.

Hay una implementación paralela de la aplicación en otro puerto - stemhub.org:5000 - que se está ejecutando en Tornado y funciona bien, al igual que la versión de desarrollo local.

Estos son los bookmarklets, sobre la posibilidad de que el problema son:

puerto de trabajo 5000 Versión: javascript:(function(){window.open('http://stemhub.org:5000/submit/'+encodeURIComponent(window.location.href),'height=200,width=150')}())

puerto problema versión 80: javascript:(function(){window.open('http://stemhub.org/submit/'+encodeURIComponent(window.location.href),'height=200,width=150')}())

ACTUALIZACIÓN: Por alguna razón que pertenece a otra etiqueta de cambiar el método de Javascript encodeURIComponent a encodeURI hace que todo funciona como es debido, al menos en FF y Chrome. Tomará el consejo de Graham Dumpleton de algo más sensato para esto en el futuro, sin embargo.

Answer 1

Cualquiera que sea su problema es, la forma en que está poniendo una segunda URL dentro de la URL no funciona con Apache. Esto se debe a Apache se derrumbará barras de repetición en una única barra y que sola barra es entonces todo lo que la aplicación recibido por Apache veremos en PATH_INFO.

En otras palabras, no es una cuestión mod_wsgi y podría ocurrir si se utiliza otra aplicación dinámica de alojamiento web mecanismos en conjunto con Apache, incluso no Python.

Por cierto, algunos pueden señalar que la URL no modificada está en REQUEST_URI, pero confiando en que no es necesariamente una buena idea ya que la elaboración de cómo dividir eso y mapa contra SCRIPT_NAME y PATH_INFO no siempre es sencillo dependiendo de si las reglas de reescritura se utilizan en Apache.

Sugiere que en lugar de investigar la segunda URL formar parte de una cadena de consulta y no la ruta URL.