È accettabile aggirare le assurdità di .htaccess di Apache in un'altra lingua?

Question

È accettabile aggirare le assurdità di .htaccess di Apache in un'altra lingua?

#1 da (4 voti)
#2 da (3 voti)
#3 da (0 voti)

2

Mi sto ammalando di tutte le stranezze di Apache e sto pensando di iniziare a evitare .htaccess il più possibile per scrivere un codice reale e prevedibile. Sarebbe facile e diretto emulare cose come la sicurezza e la riscrittura dei file e controllare con precisione ciò che è e non è ereditato tra le directory senza dover usare direttive strane e ottuse. Ci sarebbero degli aspetti negativi in questo?

Sto parlando di sostituire, ad esempio, questo:

# .htaccess
RewriteCond %{HTTP_USER_AGENT} blah
RewriteRule ^(.*)$        /test$1 [R=301,L]

con qualcosa di simile:

# PHP, in a header file
if(strpos($_SERVER['HTTP_USER_AGENT'], 'blah') !== false)
    redirect(301, '/test' . $_SERVER['REQUEST_URI']);

Per ripetere la domanda, quali sarebbero i lati negativi dell'implementazione della funzionalità in PHP che è tradizionalmente gestita da .htaccess ?

php apache

posta Note to self - think of a name 09.12.2010 - 00:49

fonte

3 risposte

Leggi altre domande sui tag php apache

come esprimere flussi alternativi nel diagramma di attività Pensiero dello sviluppo del cloud / Google App Engine [chiuso]

score 4 · Answer 1

Le prestazioni e la scalabilità sono i due motivi principali per cui Apache fa il lavoro anziché un app server (codice PHP ospitato, Java Servlet, Ruby on Rails, Asp.NET, ecc.). Essenzialmente Apache è molto bravo a gestire un gran numero di richieste, e le versioni 2.x usano I / O non bloccanti, il che significa che può funzionare con molte più richieste rispetto ai processi e ai thread in uso. Questa è una buona cosa.

Il codice ospitato solitamente fa alcune ipotesi nel tentativo di semplificare la programmazione, come l'ambiente di codice che ha accesso completo a un thread. Non importa quanto sia efficiente la tua soluzione, non sarai in grado di scalare con garbo a meno che la tua piattaforma non funzioni allo stesso modo del server Apache.

score 3 · Answer 2

Ho scritto un framework per il mio uso che elimina tutte le riscritture ma uno - riscrivi (non reindirizza) tutto su un singolo index.php. Quell'index.php crea un'istanza del controllore del framework e poi indica quali percorsi esistono nel sito:

// Create paths for this site
$controller->addPath('/path', 'templatename, 'MyClass::someCodeToRun');

Ovviamente c'è di più rispetto a questo (principalmente percorsi dinamici, modelli nidificati e sicurezza), ma questa è l'idea di base.

Questo è ciò che fanno molti framework, e lo raccomando davvero: non è necessario arrivare a (molto) un prezzo di prestazioni se il tuo framework è leggero e includi solo ciò che ti serve per ogni percorso. L'unico prezzo di rendimento è essenzialmente la tabella di ricerca (che è solo un array associativo) per cui il percorso fa cosa.

Penso che la migliore organizzazione del codice possa spesso diventare una vinci .

score 0 · Answer 3

0

Prestazioni, probabilmente ...

Inoltre, i due comportamenti che descrivi non sono gli stessi: una riscrittura non è la stessa di un reindirizzamento 301.

risposta data 09.12.2010 - 01:02

fonte