Czym się różni $_SERVER['REQUEST_URI'] od $_GET['path']

Zasadniczo to wiem, co te dwie rzeczy robią i z grubsza się pokrywają. I stąd moje pytanie - która opcja jest lepsza/polecana, albo z której lepiej nie korzystać, bo jest obsolete czy deprecated ;)

Porobiłem kilka testów, przejrzałem net i nie znalazłem odpowiedzi, która opcja jest lepsza, z której powinienem skorzystać (albo inaczej - której lepiej unikać). Mam aktualnie zrobiony prosty router - wszystkie wejścia na stronę trafiają do index.php (technicznie rzecz biorąc, ten plik nazywa się u mnie inaczej, ale nie ma to tutaj żadnego znaczenia). I potem muszę przetworzyć URL wprowadzony przez usera i na tej podstawie wykonać pewne akcje. Niestety, oba sposoby działają prawie tak samo i nie wiem, którą wersję wybrać - czy $_SERVER czy tradycyjnie $_GET.

Powiedzmy, że w przeglądarce wpiszę https://jakas.domena/raz/dwa/////trzy/cztery////piec?dupa=kaczuszka (te nadmiarowe ukośniki to celowo - bo testowałem wieeeele różnych wariantów, w których może wyjść różnica miedzy tymi dwiema opcjami).

$_SERVER['REQUEST_URI']; zwraca /raz/dwa/////trzy/cztery////piec?dupa=kaczuszka
$_GET['path']; zwraca raz/dwa/trzy/cztery/piec
Czyli efekt prawie taki sam - pierwsze przekazuje dosłownie to, co zostało wpisane do przeglądarki, opcja druga wywala ukośnik z początku oraz wszystkie zduplikowane i odcina wartości przekazywane w URL'u. Pierwsze przekazuje ścieżkę razem z wartością dupa, a w drugim przypadku trzeba skorzystać z $_GET['dupa'];. Szukając różnic sprawdziłem też przesyłanie wartości przez $_POST, ale to także działa, więc naprawdę, nie mam pomysłów, co jeszcze sprawdzić.

To, co napisałem powyżej to jest raczej kosmetyka, mi się bardziej podoba drugi wariant. Ale może są jakieś powody/okoliczności o których nie wiem i które wskazują, że lepiej jest skorzystać z konkretnego wariantu - np. bezpieczeństwo, planowany brak wsparcia, jakiś brak kompatybilności itp. Wszystkie sugestie mile widziane.

Pierwsze słyszę o czymś takim jak $_GET['path']. Z tego cowiem $_GET jest uzupełniony tylko parametrami z query-string, czyli w Twoim przykładzie ze slashami ?dupa=kaczuszka byłoby tam tylko $_GET['dupa']. Klucza 'path' powinno tam nie być, przynajmniej w vanilla PHP.

Może tak być jeśli jakąś biblioteka, framework dokładają coś do $_GET (ale nie słyszałem o żadnej która tak robi), może być też tak że Twój server Ci dokleja query-param path, ale to byłoby mega słabe.

cerrato napisał(a):

Zasadniczo to wiem, co te dwie rzeczy robią i z grubsza się pokrywają. I stąd moje pytanie - która opcja jest lepsza/polecana, albo z której lepiej nie korzystać, bo jest obsolete czy deprecated ;)

Pierwsza ($_SERVER['REQUEST_URI'];) według mnie robi to co chcesz. Po prostu odczytuje informacje o URI (a więc host, domenę, port, path, query params oraz anchor). Czyli scheme://domain:port/path/path?#anchor?query=param&query2=param

$_GET odczytuje tylko i wyłącznie parametry z query-string, bez patha i anchora.

Z różnic jakie są, to REQUEST_URI jest url-encoded, czyli jeśli już sparsujesz url, to na danych musisz zrobić urlDecode(). W $_GET są już zdekodowane.

Te nazwy są trochę skopane. W $_POST jest body requestu, a w $_GET są query string, nie ważne jaką metodą zostały wysłane. Request DELETE, PATCH czy nawet POST wysłany z query paramsami wsadzi te paramsy do $_GET.

Polecam nie używać pure php, tylko bundla Request od symfony, albo jakiegoś innego do wyciągania rzeczy z requesta.

@cerrato: a nie wrzuciłeś czasem w .htaccess instrukcji, która zamienia ci ścieżki na parametr path? Bo tak to właśnie wygląda. Ja tak robiłem tworząc swój framework.

Dobra, sprawdziłem i jak pisał @ehhhhh - przerzucenie tego jako $_GET['path'] wynika z wpisu w .htaccess. Totalnie mi ten aspekt uciekł/zapomniałem o tej kwestii :/

Plik z przekierowaniem ma następującą postać:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /index.php?path=$1 [NC,L,QSA]

W związku z tym ponawiam pytanie - jaką widzicie różnicę pomiędzy stosowaniem dwóch opisanych na samym początku sposobów dobrania się do URL'a? Który jest lepszy/gorszy i dlaczego?

Skoro sam wymuszasz path to możesz z niej na spokojnie korzystać. Tylko polecam zrobić taka nazwę by jej potem nigdzie jako parametr w urlu nie użyć.

ehhhhh napisał(a):

Skoro sam wymuszasz path to możesz z niej na spokojnie korzystać. Tylko polecam zrobić taka nazwę by jej potem nigdzie jako parametr w urlu nie użyć.

Słuszna uwaga, aczkolwiek raczej nie będzie słowa path w URL, a wszystkie dane do skryptu będą przesyłane POST, więc tym bardziej nie będzie ryzyka że się ta nazwa na coś nałoży.

No jeżeli, ta wartość path, nie wynika z natury php, tylko jest dodana przez dodatki takie jak .htaccess, to logicznym jest, użycie $_SERVER, takie rozwiązanie jest bardziej uniwersalne, bo nie wymaga, określonych ustawień w .htaccesie, no, ale nie wiem, czy ktoś to tutaj zrozumie :)

@omenomn2: htaccess rozprowadzasz z aplikacją jako jej integralna część a dodatkowo dajesz w readme jakie ustawienia zastosować przy nginxe. Jest to naturalne podejście nie tylko dla customowych rozwiązań ale każdego serwisu. Wystarczy sobie spojrzeć do repo jakiegokolwiek frameworka czy gotowego rozwiązania pokroju wp.

@ehhhhh

@omenomn2: htaccess rozprowadzasz z aplikacją jako jej integralna część a dodatkowo dajesz w readme jakie ustawienia zastosować przy nginxe. Jest to naturalne podejście nie tylko dla customowych rozwiązań ale każdego serwisu. Wystarczy sobie spojrzeć do repo jakiegokolwiek frameworka czy gotowego rozwiązania pokroju wp.

No zupełnie nie, w życiu się z paczką żadną nie spotkałem, która wymaga jakichś ustawień w .htaccessie.
Ponad to, jeżeli masz już w apce konkretne ustawienia .htaccessa, to one mogą wykluczać ustawienia z tego kodu.
Kod powinien być reużyteczny, a w tym przypadku jego ponowne użycie w innym projekcie jest utrudnione, przez dodatkowe, zbędne ustawienia, bo ktoś sobie stwierdził, że będzie path pobierać z geta, zamiast z serwera.
Tak jak mówiłem, będzie to raczej ciężkie do zrozumienia osobom, co tylko czytają kod źródłowy, zamiast zastanowić się i poczytać na temat dobrych praktyk.
Właśnie dlatego jestem za używaniem bibliotek, szczególnie do takich trywialnych rozwiązań, bo to już jest dawno ogarnięte, a tutaj zamiast wypluć funkcjonalność, autor marnuje czas na zastanawianie się nad błędnymi rozwiązaniami.

Jeżeli mowa o frameworkach to tak, ale .htacces jest w nich stosowany, nie do pobierania z geta, patha urla, tylko innych rzeczy.

Jeżeli autor chcę napisać dobry kod, do wyciągania requesta i koniecznie nie chcę zewnętrznych bibliotek, to niech chociaż sprawdzi jak one są napisane i stworzy coś podobnego dobrego.

Kod jest nadal reużywalny ale trudno to zrozumieć osobom, które maja ograniczenie w rozumieniu systemów.

Kod jest nadal reużywalny ale trudno to zrozumieć osobom, które maja ograniczenie w rozumieniu systemów.

Nie jest, a jeśli jest, to w sposób niepotrzebnie utrudniony przez zbędne dodatki.

Pokaż mi popularny framework lub cms który nie wymaga ręcznej konfiguracji nginxa.

No choćby Laravel nie wymaga dodatkowej konfiguracji nginxa.
Jeżeli masz na myśli .htaccess to owszem jest zdefiniowany do tworzenia przyjaznych urli itd., ale sama biblioteka do wyciągania requestów nie wymaga .htaccessa, powinienieś to wiedzieć skoro tak znasz na pamięć wszystkie biblioteki.

W ogóle ta reguła w .htaccessie jest, niepotrzebna, jak się chce mieć ładne urle, to się inne reguły stosuje.
Można podejrzeć .htaccessa z Laravela.

Ależ oczywiście że htaccess lub config nginxa jest wymagany w laravelu. Spróbuj go usunąć i korzystać z metod route i action, gdzie każdy wie, żeby urle robić tylko przez te metody.

Ależ oczywiście że htaccess lub config nginxa jest wymagany w laravelu. Spróbuj go usunąć i korzystać z metod route i action, gdzie każdy wie, żeby urle robić tylko przez te metody.

Przecież napisałem, że jest wymagany w Laravel, ale do wyciągania danych z requesta nie jest (sam komponent Request), coś Ci to czytanie kodów źródłowych nie poszło.
Każdy path jest przekierowywany na index.php, to jest oczywiste, ale ta reguła z .htaccessa autora, jest zbędna i błędna.
Pewnie nie korzystałeś z samego komponentu Request bundla od Symfony, we własnym projekcie, bo Ci nie starczyło czasu, po czytaniu bibliotek, ale jakbyś korzystał to byś wiedział, że sam komponent odpowiedzialny za pobieranie requesta nie wymaga .htaccessa i można z niego korzystać jak masz ścieżki bezpośrednio do plików php, czyli index.php, contact.php itd.

Czyli teraz obracasz kota ogonem zmieniając narracje, że sama biblioteka to umożliwia no spoko :p