Niespójny końcowy ukośnik w zmiennej DOCUMENT_ROOT w PHP podczas używania Apache

10

W różnych środowiskach serwerowych $_SERVER['DOCUMENT_ROOT']super globalny PHP czasami ma końcowe ukośniki, a czasem nie. Wydaje mi się, że ten problem jest bezpośrednio związany ze DocumentRootzdefiniowaniem Apache w httpd.confpliku:

tzn. pomyślałbym, że jeśli httpd.confnie zawiera końcowego ukośnika:

<VirtualHost *:8880>
    DocumentRoot /var/www/live/current
    ...

następnie echo $_SERVER['DOCUMENT_ROOT']powinien dać / var / www / live / current

a jeśli httpd.confzawiera ukośnik:

<VirtualHost *:8880>
    DocumentRoot /var/www/live/current/
    ...

następnie echo $_SERVER['DOCUMENT_ROOT']powinien dać / var / www / live / current /

Tak jest w przypadku Ubuntu 10.04, ale w RHEL 5.5 dodawany jest ukośnik końcowy, $_SERVER['DOCUMENT_ROOT']nawet jeśli nie został zdefiniowany w Apache.

Wiesz, dlaczego tak się dzieje? Czy brakuje mi parametru konfiguracyjnego?

Na przykład:

  • PHP 5.3.3 z RHEL (problem występuje): PHP 5.3.3 (cli) (zbudowany: 23 lipca 2010 16:26:53)
  • Ubuntu w wersji PHP (bez problemu): PHP 5.3.2-1ubuntu4.2 z łatką Suhosin (cli) (zbudowany: 13 maja 2010 20:03:45)
apache-2.2 php configuration documentroot Tomek
źródło

Odpowiedzi:

6

Nie mam pojęcia, dlaczego ukośnik zmienia się między wirtualnymi hostami. Nawiasem mówiąc, czy to ważne? Po prostu dodaj nowy ukośnik do swoich programów (usuń, jeśli występuje podwójny ukośnik), a problem zostanie rozwiązany.

używam 

$realpath = realpath ($_SERVER['DOCUMENT_ROOT']."/");
$realpath = str_replace ("//", "/", $realpath);
Dom
źródło
4
Możesz po prostu użyć $realpath = realpath($_SERVER['DOCUMENT_ROOT']);. Automatycznie usuwa wszystkie wielokrotne ukośniki, a także końcowy. Jeśli zawsze chcesz końcowego ukośnika połączyć go z wynikiem powyższego wywołania do realpath(). Nie w środku.
grypa
1
Mogę potwierdzić ten sam problem (php 5.5) między hostem Hosteurope (myślę, że Ubuntu): ma slash ... i Windows 7: bez slash (dość niedawna instalacja XAMPP)
Frank Nocke
rtrim($_SERVER['DOCUMENT_ROOT'],'/\\').'/'powinien być nieco szybszy niż wszystkie te rzeczy, które może zrobić prawdziwa ścieżka.
Frank Nocke,
3

Katalog główny w środowisku Apache można zdefiniować w więcej niż jednym miejscu.

Tak, httpd.confzawiera te ustawienia, ale można je zastąpić, ponieważ ten plik jest używany do konfiguracji domyślnej.

Sugeruję, abyś sprawdził konfigurację vhost pod vhosts.di sites-availablekatalogami.

veidelis
źródło
2

Proponowane rozwiązanie:

$realpath = realpath ($_SERVER['DOCUMENT_ROOT']."/");
$realpath = str_replace ("//", "/", $realpath);

nie działa we wszystkich instalacjach.

Na przykład w moim przypadku:

$_SERVER['DOCUMENT_ROOT']  = "/www/site/"
$_SERVER['DOCUMENT_ROOT']."/" = "/www/site//"
realpath("/www/site//") = "/www/site"
str_replace("//", "/", "/www/site") = "/www/site"

Ten sam problem jak poprzednio.

Być może powinieneś zmodyfikować pierwszą instrukcję w:

$realpath = realpath ($_SERVER['DOCUMENT_ROOT'])."/";

oset

Antonio
źródło
1
rtrim($_SERVER['DOCUMENT_ROOT'],'/\\').'/'powinien być nieco szybszy niż wszystkie te rzeczy, które może zrobić prawdziwa ścieżka.
Frank Nocke
2

Odpowiedź Dom jest rozwiązaniem tego problemu, jednak wypowiedź Stefanaveski jest przyczyną, dla której w różnych środowiskach występuje podwójne „//”. Na komputerze lokalnym, w pliku .conf, w którym skonfigurowano wirtualnego hosta, najprawdopodobniej dodano / na końcu zdefiniowanego katalogu głównego dokumentu, podczas gdy osoba, która skonfigurowała inne środowisko, nie zrobiła tego lub odwrotnie.

Tak czy inaczej, podczas korzystania z $ _SERVER ['DOCUMENT_ROOT'] php otrzymujesz wartość środowiska apache, która jest wynikiem konfiguracji. To jest powód „/” w jednym środowisku i „//” w innym.

Ben Smith
źródło
1

Powiedziałbym, że założono, że DOCUMENT_ROOT nie ma ukośnika końcowego.

Ta wartość jest przekazywana z konfiguracji serwera WWW

apacz

DocumentRoot /var/www/html

Oznacza to, że powinniśmy mieć wiodący ukośnik do ścieżki, którą do niego dodamy.

Wiedząc, że podwójne ukośnik „//” w dowolnym miejscu na ścieżce nie ma konsekwencji (w przypadku systemu plików ... w adresie URL mogą wystąpić przypadki, w których występują pewne usterki)

$ cat /etc//issue Debian GNU/Linux 9 \n \l

Kiedy pojawia się ukośnik do DOCUMENT_ROOT, możemy winić sysadmin za coś, co nie ma konsekwencji :)

I bezpiecznie to zignorować?

Antony Gibbs
źródło