Apache2: 400 Bad Request con regole di riscrittura, nulla nel log degli errori?

Questo mi sta guidando.

Background: Sto usando il built-in Apache2 e PHP che viene fornito con Mac OS X 10.6

  • Come creare il file di backup del database mysql di each aggiornamento quotidiano?
  • Nome di dominio singolo potenzialmente risolvente a più server
  • È sicuro archiviare gli script di shell in / var / www?
  • Protezione codice PHP
  • Perché il mio htaccess redirect non funziona?
  • Errore di Apache SSL dopo il riavvio: errore 107 (net :: ERR_SSL_PROTOCOL_ERROR)
  • Ho un setup vhost come segue:

    NameVirtualHost *:81 <Directory "/Users/neezer/Sites/"> Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all </Directory> <VirtualHost *:81> ServerName lobster.dev ServerAlias *.lobster.dev DocumentRoot /Users/neezer/Sites/lobster/www RewriteEngine On RewriteCond $1 !^(index\.php|resources|robots\.txt) RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php/$1 [L,QSA] LogLevel debug ErrorLog /private/var/log/apache2/lobster_error </VirtualHost> 

    Ciò è in /private/etc/apache2/users/neezer.conf .

    Il mio codice nel lobster project è PHP con il framework CodeIgniter . Cercando di caricare http://lobster.dev:81/ mi dà:

    400 Richiesta non valida

    Normalmente, vado a controllare i miei registri per vedere cosa ha causato, ma i miei registri sono vuoti! Ho guardato in entrambi i /private/var/log/apache2/error_log e /private/var/log/apache2/lobster_error e né registro alcun messaggio relativo al 400. Ho impostato LogLevel per debug in /private/etc/apache2/http.conf .

    Rimuovendo le regole di riscrittura si libera l'errore, ma queste stesse regole funzionano sul mio host MAMP. Ho rewrite_module controllo e rewrite_module è caricato nell'imansible installazione di Apache. Il mio http.conf può essere trovato qui: https://gist.github.com/1057091

    Che cosa dà? Fammi sapere se hai bisogno di ulteriori informazioni.

    NOTA: non voglio aggiungere le regole di riscrittura a .htaccess nella directory del progetto (è controllata in un repo di git e non voglio toccarlo).

  • La latenza di Ubuntu HTTP che cade in quantili strani
  • Ubuntu 8.04 LTS kernel NULL puntatore dereference
  • lsync, unison o qualche altro inotify strumento di sincronizzazione automatica ..?
  • Salta sul server intermedio tramite SSH
  • Impostazione del fuso orario con uno script automatico
  • Keepalived per più di 20 indirizzi virtuali
  • 3 Solutions collect form web for “Apache2: 400 Bad Request con regole di riscrittura, nulla nel log degli errori?”

    Per le regole mod_rewrite complicate, è una buona idea registrare la sequenza degli events per vedere cosa sta succedendo. Fai questo con RewriteLog e ruota la RewriteLogLevel per vedere i dettagli.

    mod_rewrite è molto flessibile e si può fare molte cose con le regole di riscrittura, ed è anche abbastanza complicato. Un outsider ha difficoltà a eseguire il debug di regole senza vedere il context più ampio. La cosa migliore che puoi fare per debuggire da soli. Guarda i registri di una window mentre si sperimentano le modifiche di configuration in una seconda window. Fare una piccola modifica, salvare il file, ricaricare apache e riprendere nuovamente l'URL. Ripetere.

    Ecco una buona descrizione di RewriteLog dal manuale di Apache:

    Riscrivere il registro

    Quando si utilizzano le potenti e complesse funzionalità di mod_rewrite, è quasi sempre necessario utilizzare il RewriteLog per aiutare a eseguire il debug. Questo file di registro produce un'analisi dettagliata di come il motore di riscrittura trasforma le richieste. Il livello di dettaglio è controllato dalla direttiva RewriteLogLevel.

    La sostituzione nel context <virtualhost> utilizza un URL non assoluto. Non puoi farlo al di fuori del context Directory / htaccess.

    Alcune altre note, che sono diventate un po 'troppo grandi per essere contenute in un semplice commento:

    RewriteCond $1 funziona, ma è abbastanza pericoloso e fragile. In particolare, si potrebbe facilmente riscrivere il RewriteRule in modo da distriggersre completamente la funzionalità di quella RewriteCond e non avresti mai saputo di averlo fatto. L'utilizzo di %{REQUEST_URI} si consiglia come soluzione, à la RewriteCond %{REQUEST_URI} ^/(index\.php|resources|robots\.txt) .

    Prossimo numero: queste due linee:

     RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d 

    non sono funzionali come presentati. Devono essere posizionati all'interno di una stanza <Directory> o modificati per utilizzare le macro di RewriteCond %{LA-U:REQUEST_FILENAME} !-f (ad esempio RewriteCond %{LA-U:REQUEST_FILENAME} !-f ).

    La causa effettiva di che hai bisogno di rimuovere / è che .htaccess elimina il primo / primo argomento di RewriteRule, mentre è consegnato con / intatto a RewriteRules in httpd.conf (o dei suoi file d Include ), cosa che è importnte da ricordare nel caso in cui si cerchi mai di spostare questa regola in un .htaccess. È ansible rielaborare la regola come .htaccess / httpd.conf-agnostic facendo qualcosa come RewriteRule ^/?(.*)$ index.php/$1 [L,QSA] .

    Un'ultima nota: come puoi vedere nella regola sopra, non c'è bisogno di sfuggire al / con un backslash.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.