SORU
16 HAZİRAN 2010, ÇARŞAMBA


Apache Special direktifleri ortam değişkenleri ayarlarken, ne değişken adı öneki neden olur &; değişkenlerinin isimlerinin başına redırect_""?

Bir Special kuralları [E=VAR:VAL] bayrağı ile Apache ortam değişkenleri (PHP içinde kullanmak için) ayarlamak için çalışıyorum .dosya debug.

Zaten değişkenleri sunucu değişkenler PHP $_SERVER yerine $_ENV anlamda belirli bir miktar yapar) erişilen keşfettim. Ancak, benim sorunum için bazı kurallar [E=VAR:VAL] bayrağı işler beklendiği gibi ve ben sonunda bir değişken $_SERVER['VAR'] ama diğer kuralları Ben son bir değişken $_SERVER['REDIRECT_VAR'] $_SERVER['REDIRECT_REDIRECT_VAR'] vb

Bir ortam değişkeni Apache set nedenleri A. [E=VAR:VAL] bayrak "" değişken adının başına? değişkenlerinin isimlerinin başına redırect_ alarak yeniden kullanma

B. Ne yapabilirim emin olmak için ben bir erkeğim, bir Ortam Değişkeni ile değişmeden name yani erişim PHP gibi $_SERVER['VAR'] zorunda kalmadan başvurmak için kontrol etmek için varyasyonları değişken adı bir daha örnekleri "değişkenlerinin isimlerinin başına redırect_" e?

Kısmi çözüm bulundu. Eğer ihtiyaç olursa her yeniden yeniden yazma kuralları orijinal ENV:VAR yeniden oluşturur, başlangıç olarak REDİRECT_VAR sürümleri orada bırakarak) için aşağıdaki eklemek için:

RewriteCond %{ENV:REDIRECT_VAR} !^$
RewriteRule .* - [E=VAR:%{ENV:REDIRECT_VAR}]

CEVAP
12 NİSAN 2012, PERŞEMBE


Ugh, bu davranışı çok sinir bozucu. Hatta belgelenen görünmüyor.

Not: Derin benim orijinal sonrası bu (ugh) araştırdım, bu gerçekten mide düzenlendi.

.başına-dir debug bağlam

Burada .htaccess her dizin (per-dir) kapsamında gerçekleşmiş gibi görünür:

Apache yeniden direktifleri içeren .htaccess dosya işlemleri varsayalım.

  1. Apache standart CGI / Apache tüm değişkenleri ile çevre değişkenini göster doldurur

  2. Yeniden başlar

  3. Çevre değişkenleri RewriteRule direktifler bulunmaktadır

  4. Ne zaman Apaçi durur işleme RewriteRule direktifleri (çünkü bir L bayrak veya son kural setleri) ve URL değiştirildi by RewriteRule Apache yeniden işleme isteği.

    Eğer bu bölüm hakkında bilginiz varsa, L flag documentationbakın:

    böylece kural dizisinin tekrar baştan çalıştırmak olabilir. En sık bu kurallardan biri yönlendirme - iç veya dış - istek neden olan bir süreci başlatmak için neden olur.
  5. Ne yapabilirim gözlemlemek, sanırım o zaman #4 olur, #1 tekrarlanır, sonra ortam değişkenleri vardı set RewriteRule direktifleri ve E ile "değişkenlerinin isimlerinin başına redırect_" ve ekledi, çevre değişkenleri göster (sırası değişebilir, ama sonuçta oluşan bu kombinasyonu).

    Bu adım, seçilen değişken isimlerini sildi, ve bir anda bu kadar önemli ve zahmetli bir iştir nedenini açıklayacağım.

Değişken isimleri kullanın

Ben aslında bu sorunla karşılaşınca, .htaccess aşağıdaki (basitleştirilmiş) gibi bir şey yapıyordum:

RewriteCond %{HTTP_HOST} (. )\.projects\.

RewriteRule (.*) subdomains/%1/docroot/$1

RewriteRule (. /docroot)/ - [L,E=EFFECTIVE_DOCUMENT_ROOT:$1]

Ben set ortam değişkeni ilk RewriteRule Apache olur yeniden yeniden yazma süreci ve önüne değişkeni ile "değişkenlerinin isimlerinin başına redırect_" (adım #4 ve 5 üzeri), böylece ederdim kaybetmek erişimi ile adını verdiğim.

Bu durumda, ilk RewriteRule URL değişiklikleri, RewriteRules hem işlendikten sonra, Apache prosedürü yeniden ve yeniden .htaccess bu işlemler. İkinci kez RewriteRule RewriteCond direktifin kaçmış olmasıdır, ancak ikinci RewriteRule maçlar ilk, ortam değişkeni (tekrar), ve daha da önemlisi, ayarlarURL değiştirmez. İstek / yeniden yazma süreci başlatılmaz ve değişken adı ben sopa seçti. Bu durumda ben aslında REDIRECT_EFFECTIVE_DOCUMENT_ROOT EFFECTIVE_DOCUMENT_ROOT her ikisi de var. Eğer ilk L bir bayrak kullansam RewriteRule sadece EFFECTIVE_DOCUMENT_ROOT olurdu.

@Mala ... ... kısmi çözüm benzer şekilde çalışır: yeniden direktifleri işlenmiş yine, yeniden adlandırılan bir değişken atanır orijinal adı tekrar, ve eğer URL değişmez, işlem bitti ve atanmış değişken adı sopa.

Neden bu teknikler yetersiz kalmaktadır

Hem bu teknikleri muzdarip bir büyük kusuru: ne zaman yeniden yazma kuralları .htaccess dosyası nerede ayarladığınız ortam değişkenleri yeniden yazma URL için daha fazla iç içe dizin vardır .htaccess dosyası olan herhangi bir yeniden yazma, atanan değişken ismi sildi tekrar.

Bu gibi: bir dizin düzeni var

docroot/
        .htaccess
        A.php
        B.php
        sub/
                .htaccess
                A.php
                B.php

Ve bu gibi docroot/.htaccess:

RewriteRule ^A\.php sub/B.php [L]

RewriteRule .* - [E=MAJOR:flaw]

/A.php, istek ve 44 ** için yazılmış. Hala MAJOR değişken var.

Eğer docroot/sub/.htaccess direktifleri (sadece RewriteEngine Off RewriteEngine On bile) yeniden varsa, ancak, MAJOR değişken kaybolur. Bu URL sub/B.php, docroot/sub/.htaccess için yazılmış bir kez işlenir, ve eğer direktifleri yeniden varsa herhangi bir Direktif tekrar işlenmez yeniden yazmak için. Varsa REDIRECT_MAJOR sonra docroot/.htaccess işlenmiş (örn atlarsanız L bayrağı ilk RewriteRule), hala var, ama bu direktifler bile oynamaz yeniden ayarlamak için seçilen değişken adı.

Miras

Demek istiyorsun ki:

  1. set ortamı dizin ağacı (docroot/.htaccessgibi), belirli bir düzeyde RewriteRule direktifler değişkenleri

  2. daha derin seviyelerde komut kullanılabilir onları

  3. atanan isimler mevcut onları

  4. iç içe .htaccess daha dosyalarındaki yönergelerin yeniden var edebilmek

Olası bir çözüm daha fazla iç içe .htaccess dosyaları RewriteOptions inherit yönergeleri kullanın. Bu yeniden çalıştırmak daha fazla iç içe dosyalarındaki yönergelerin yeniden yazmak ve Teknikleri yukarıda belirtilen seçilmiş isimleri ile değişkenlerini kullanmak için izin verir. Ancak, bu artışlar karmaşıklığı nedeniyle olman daha dikkatli işçiliği yeniden puanına daha fazla iç içe geçmiş dosyaları, böylece yok neden sorunlar çalıştırmak daha fazla iç içe dizin. Apache başına dır daha fazla iç içe dizin öneki şeritler ve bu değer üzerinde daha fazla iç içe dosyalarındaki yönergelerin yeniden çalışır inanıyorum.

@Mala tekniği

Bildiğim kadarıyla görebiliyorum, destek için kullanan bir yapı gibi %{ENV:REDIRECT_VAR} değeri bileşeni RewriteRule E bayrak (örneğin [E=VAR:%{ENV:REDIRECT_VAR}]) görünmez olmak documented:

VAL geribaşvuruların içerebilir ($N %N) genişletilmiş olacak.

Çalışmak için görünmüyor, ama eğer bir şey belgesiz (lütfen eğer bu konuda yanılıyorsam beni düzeltin) güvenerek önlemek istiyorsanız, kolayca yerine bu şekilde yapılabilir:

RewriteCond %{ENV:REDIRECT_VAR} (. )
RewriteRule .* - [E=VAR:%1]

SetEnvIf

Bilmiyorum tavsiye güvenerek bu, çünkü görünmüyor tutarlı documented behavior (aşağıya bakınız), ama bu (docroot/.htaccess, Apache 2.2.20) benim için çalışıyor:

SetEnvIf REDIRECT_VAR (. ) VAR=$1

Sadece bu ortam değişkenleri önceki SetEnvIf[NoCase] direktifleri tarafından tanımlanan bu şekilde test için kullanılabilir.

Neden?

Bilmiyorum ne için gerekçe başına bu isimleri "değişkenlerinin isimlerinin başına redırect_" -- hiç de şaşırtıcı değil, o zaman gibi görünmüyor bahsedilen Apache belgelerine bölümler için mod_rewrite directives, RewriteRule flags ya environment variables.

Şu anda tek başına atanan isim bırakmaktan daha iyidir neden bir açıklama olmaması benim için büyük bir sıkıntı gibi görünüyor. Belgelerin eksikliği sadece bu konuda benim şüphecilik katkıda bulunur.

Yeniden ortam değişkenleri atamak için güçlü olmak kuralları yararlıdır, ya da en azından olurdu. Ama yararı büyük ölçüde isim değişen bu davranış yüzünden azalıyor. Bu yazının karmaşıklığı fındık bu davranış ve bunu aşmak için denemek için atladı aracılığıyla olmak zorunda çemberler nasıl gösterir.

Bunu Paylaş:
  • Google+
  • E-Posta
Etiketler:

YORUMLAR

SPONSOR VİDEO

Rastgele Yazarlar

  • FND Films

    FND Films

    2 Mayıs 2006
  • MrExcite96

    MrExcite96

    17 ŞUBAT 2011
  • XxMinayaxX1

    XxMinayaxX1

    9 Mayıs 2012