mod_wsgi comportamento imprevisto sul bookmarklet presentare o correlata azione di database

Question

[aggiornato sotto]

Ho un po 'un problema la distribuzione di un sito su Apache con mod_wsgi con alcune funzionalità javascript bookmarklet; sito alpha è attivo e utilizzabile qui: stemhub.org . Il problema è che il bookmarklet (che è un pulsante del menu del browser) sottopone a una pagina come

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

che poi restituisce una forma per salvare i metadati relativi link. La funzione di visualizzazione (un pallone / werkzeug app) controlla il database per vedere se è già stato aggiunto il link, quindi restituisce il modulo con un ID di collegamento o pre-esistenti o appena assegnato, per cui direi che potrebbe innescare un qualche tipo di problema di temporizzazione. Molto strano, quando ho presento il collegamento, ottengo la pagina http://stemhub.org/submit/http://the-users-link.com/here con un "non trovato" apache errore, ma se poi ricaricare la pagina, ottengo il modulo come previsto. log di errore contengono messaggi sulla filettatura delle eccezioni, ma lo fanno quando i perfoms site come previsto, anche.

C'è una distribuzione parallela di app su un'altra porta - stemhub.org:5000 - che è in esecuzione su Tornado e funziona bene, così come la versione di sviluppo locale.

Ecco i bookmarklet, sulla possibilità che sono il problema:

porto di lavoro 5000 versione: javascript:(function(){window.open('http://stemhub.org:5000/submit/'+encodeURIComponent(window.location.href),'height=200,width=150')}())

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

UPDATE: Per qualche ragione che appartiene ad un altro tag cambiare il metodo javascript encodeURIComponent a encodeURI fa funzionare tutto come previsto, almeno in FF e Chrome. Prenderà il consiglio di Graham Dumpleton di qualcosa di più ragionevole per questo in futuro però.

Answer 1

Qualunque sia il vostro problema è, il modo in cui si sta mettendo un secondo URL all'interno dell'URL non funzionerà con Apache. Questo perché Apache collasserà barre ripetitive in una singola barra e quella singola barra è poi che la domanda ospitato da Apache vedrà in PATH_INFO.

In altre parole, non è un problema mod_wsgi e potrebbe verificarsi se si utilizza un'altra applicazione dinamica hosting meccanismi in combinazione con Apache, anche non Python.

A proposito, alcuni possono sottolineano che l'URL non modificato è in REQUEST_URI, ma basandosi su che non è necessariamente una buona idea come lavorare fuori come dividere che e mappa contro SCRIPT_NAME e PATH_INFO può non essere sempre dritto in avanti a seconda se le regole di riscrittura sono utilizzati in Apache.

suggerisco di indagare invece la seconda URL far parte di una stringa di query e non il sentiero URL.