Jest jeszcze trzeci przypadek, wiesz. !isset($_REQUEST['s']).
Franz
5
Jak ważne jest, aby inni ludzie dobrze rozumieli Twój kod? POST i GET są jawne, podczas gdy REQUEST może pochodzić z różnych źródeł. Myślę, że wydajność jest znikoma, ponieważ superglobalne REQUEST, POST i GET są zawsze ładowane dla każdego żądania.
Kevin
Odpowiedzi:
273
$_REQUESTDomyślnie zawiera zawartość $_GET, $_POSTi $_COOKIE.
Ale to tylko wartość domyślna, która zależy od variables_order; i nie jesteś pewien, czy chcesz pracować z plikami cookie.
Gdybym miał wybierać, pewnie bym nie używał $_REQUEST, a wybrałbym $_GETlub $_POST- w zależności od tego, co ma robić moja aplikacja (tj. Jedną lub drugą, ale nie obie) : ogólnie mówiąc:
Powinieneś używać, $_GETgdy ktoś żąda danych z Twojej aplikacji.
I powinieneś używać, $_POSTgdy ktoś wypycha (wstawia, aktualizuje lub usuwa) dane do twojej aplikacji.
Tak czy inaczej, nie będzie dużej różnicy w wydajności: różnica będzie znikoma w porównaniu z tym, co zrobi reszta twojego skryptu.
Idealnie byłoby, gdybyś zawsze mógł używać $ _REQUEST. Ale to oczywiście tylko doskonały świat.
Tyler Carter
2
$ _REQUEST jest rzekomo (lub przynajmniej kiedyś) droższe niż bezpośrednie użycie $ _POST i $ _GET.
Darrell Brogdon
3
+1 za koncepcję pomijalnej różnicy w wydajności i ważniejszej perspektywy konserwacji: $ _GET i $ _POST przekazują znaczenie w sposób, którego $ _REQUEST nie może.
Jon Cram
9
Użycie $ _REQUEST nie powoduje XSS / XSRF. Niezrozumienie niuansów XSS / XSRF powoduje XSS / XSRF. Tak długo, jak ograniczasz się za pomocą tokenów, nie ma problemu ORAZ uzyskujesz korzyści z używania $ _REQUEST (wszystkie twoje zmienne znajdują się w jednym superglobalnym). Właściwie odbudowuję $ _REQUEST przed użyciem go w oparciu o inne superglobale z powodu 'variable_order'. Przetwarzam $ _COOKIE, potem $ _GET, potem $ _POST. W ten sposób zmienne POST mają najwyższy priorytet, a zmienne cookie uzyskują najniższy, co pozwala mi niejawnie naprawić szereg błędów (np. Adobe Flash i magiczne cudzysłowy).
CubicleSoft
jest w nazwie, Get = get from, Post = post to
Grumpy
32
GET a POST
1) GET i POST tworzą tablicę (np. Array (klucz => wartość, klucz2 => wartość2, klucz3 => wartość3, ...)). Ta tablica zawiera pary klucz / wartość, gdzie klucze to nazwy kontrolek formularza, a wartości to dane wejściowe od użytkownika.
2) Zarówno GET, jak i POST są traktowane jako $ _GET i $ _POST. Są to superglobale, co oznacza, że są zawsze dostępne, niezależnie od zakresu - i można uzyskać do nich dostęp z dowolnej funkcji, klasy lub pliku bez konieczności wykonywania jakichkolwiek czynności specjalnych.
3) $ _GET to tablica zmiennych przekazywana do bieżącego skryptu przez parametry adresu URL.
4) $ _POST to tablica zmiennych przekazywana do bieżącego skryptu za pomocą metody HTTP POST.
Kiedy używać GET?
Informacje wysyłane z formularza metodą GET są widoczne dla każdego (wszystkie nazwy i wartości zmiennych wyświetlane są w adresie URL). GET ma również ograniczenia ilości wysyłanych informacji. Ograniczenie to około 2000 znaków. Ponieważ jednak zmienne są wyświetlane w adresie URL, można dodać stronę do zakładek. Może to być przydatne w niektórych przypadkach.
GET może służyć do wysyłania danych niewrażliwych.
Uwaga: GET NIGDY nie powinien być używany do wysyłania haseł lub innych poufnych informacji!
Kiedy używać POST?
Informacje wysyłane z formularza metodą POST są niewidoczne dla innych (wszystkie nazwy / wartości są osadzone w treści żądania HTTP) i nie mają ograniczeń co do ilości wysyłanych informacji.
Ponadto POST obsługuje zaawansowane funkcje, takie jak obsługa wieloczęściowego wejścia binarnego podczas przesyłania plików na serwer.
Jednak ponieważ zmienne nie są wyświetlane w adresie URL, nie można dodać strony do zakładek.
$ _GET pobiera zmienne z zapytania lub adresu URL.>
$ _POST pobiera zmienne z metody POST, takie jak (ogólnie) formularze.
$ _REQUEST jest połączeniem $ _GET i $ _POST, gdzie $ _POST zastępuje $ _GET. Dobrze jest używać $ _REQUEST na formularzach referencyjnych do walidacji.
+1 W zasadzie tego mnie nauczono. Nie techniczne jak inne odpowiedzi, ale dużo łatwiejsze do zapamiętania ( GETz ciągu zapytania, POSTz przesłania formularza).
jp2code
18
Sugerowałbym użycie $_POSTi $_GETwyraźnie.
Używanie $ _REQUEST powinno i tak być niepotrzebne przy odpowiednim zaprojektowaniu witryny, a ma pewne wady, takie jak pozostawienie cię otwartego na łatwiejsze CSRF/XSSataki i inne głupoty wynikające z przechowywania danych w adresie URL.
Różnica prędkości w obu przypadkach powinna być minimalna.
Dobra odpowiedź, z zastrzeżeniem, że w wielu sytuacjach GET lub POST powinny być wybierane w oparciu o sytuację, zamiast używać któregokolwiek z nich.
ceejayoz
3
Masz rację, że nikogo to nie obchodzi, ale moim zdaniem używanie $_REQUESTjest złym wnioskiem. Zobacz moją odpowiedź.
Franz
4
dlaczego użycie $ _REQUEST jest czystsze w porównaniu z $ _GET lub $ _POST? $ _REQUEST wykonuje tę samą logikę za sceną, a wybranie GET lub POST zapewnia większą kontrolę.
Jay Zeng
6
Twierdzenie, że _REQUEST jest bardziej higieniczne, wymaga dopracowania.
2
Polecam użycie GET, jeśli chcesz, aby użytkownik mógł skopiować adres URL i wykonać tę samą operację, tj. (Jego adres URL jest widoczny jak 'google.com/q=searchWord', podczas gdy POST powinien być używany do wysyłania danych do witryny internetowej które należy wstawić tylko raz lub wiele danych jest aktywnych, a użytkownik nie powinien być w stanie zachować adresu URL, tak jak wstawianie danych do baz danych, logowanie itp.
Dean Meehan
7
Nie martw się. Ale nadal powinieneś używać drugiego rozwiązania (plus dodatkowe sprawdzenie, czy żadna z tych zmiennych nie istnieje), ponieważ występują problemy z bezpieczeństwem $_REQUEST(ponieważ $_GETi $_POSTnie są jedynymi źródłami dla tej tablicy).
Wydaje mi się, że pojawił się post o problemach z $_REQUESTwczoraj. Pozwól mi to znaleźć.
Nie jest to wcale złe rozwiązanie. Zajmuje się lukami bezpieczeństwa, $_REQUESTale nadal umożliwia dostęp do tego samego skryptu w obie strony (w moim przypadku ten sam skrypt jest używany z różnymi 'akcjami' i czasami $ _GET byłoby w porządku, ale innym razem potrzebuję $ _POST, aby ukryć / zabezpieczyć dane).
Xandor
4
Istnieją pewne obawy związane z bezpieczeństwem, ponieważ haker może ustawić plik cookie, który zastąpi wartość $ _POST lub $ _GET. Jeśli masz do czynienia z poufnymi danymi, nie polecam używania $ _REQUEST. - Xandor
nie można użyć $_GETalternatywy $_POSTw niektórych przypadkach.
Kiedy ??
kiedy chcesz przesłać plik.
kiedy nie chcesz wyświetlać danych w adresie URL.
GETma również ograniczenia dotyczące ilości przesyłanych informacji. Ograniczenie to około 2000 znaków.
Inną rzeczą jest to, że jest kilka przypadków, w których nie można odzyskać danych za pomocą $_POST
Kiedy ?
kiedy dane są przekazywane w adresie URL.
Do usługi odpoczynku
`GET`-Provides a read only access to a resource.`PUT`-Used to create a new resource.
nie ma nic złego w użyciu $_REQUEST.
Ale sposobem na to jest jawne sprawdzenie $ _SERVER ['REQUEST_METHOD'], a nie poleganie na tym, że $ _POST jest puste dla GET.
Dobra rada dotycząca używania $_SERVER['REQUEST_METHOD']do sprawdzania, czy skrypt zostanie wywołany z którymkolwiek z nich. Ale stwierdzenie, że nic się nie dzieje, $_REQUESTnie jest w 100% prawdziwe. Istnieją pewne obawy dotyczące bezpieczeństwa, ponieważ haker może ustawić plik cookie, który zastąpi wartość $ _POST lub $ _GET. Jeśli masz do czynienia z poufnymi danymi, nie polecam używania $_REQUEST.
Xandor,
Dodałem Twój komentarz w mojej odpowiedzi, dziękuję Ci za pomoc
Parth Chavda
3
$ _GET pobiera zmienne z zapytania lub adresu URL.>
$ _POST pobiera zmienne z metody POST, takie jak (ogólnie) formularze.
$ _REQUEST jest połączeniem $ _GET i $ _POST, gdzie $ _POST zastępuje $ _GET. Dobrze jest używać $ _REQUEST na formularzach referencyjnych do walidacji.
Zastępowanie zależy od request_orderwartości plików cookie i może również zawierać wartości cookie, dlatego nie jest to bardzo niezawodna ani użyteczna funkcja.
Ja͢ck
1
Użyłbym drugiej metody, ponieważ jest bardziej wyraźna. W przeciwnym razie nie wiesz, skąd pochodzą zmienne.
Dlaczego mimo wszystko musisz sprawdzić zarówno GET, jak i POST? Z pewnością użycie jednego lub drugiego ma więcej sensu.
Widziałem to już wcześniej, z GETużyciem tylko jednego elementu (np. Przenoszenie go) i POSTwielu z nich (formularz z polami wyboru ...).
Franz
1
Zawsze używam tylko _GET lub _POST. Wolę mieć kontrolę.
To, co mi się nie podoba w żadnym fragmencie kodu w OP, to to, że odrzucają informacje o tym, która metoda HTTP została użyta. Ta informacja jest ważna dla oczyszczania wkładu.
Na przykład, jeśli skrypt akceptuje dane z formularza, który ma zostać wprowadzony do bazy danych, formularz powinien lepiej używać POST ( używaj GET tylko dla idempotentnych akcji ). Ale jeśli skrypt otrzymuje dane wejściowe metodą GET, to powinien (normalnie) zostać odrzucony. Dla mnie taka sytuacja może uzasadniać zapisanie naruszenia bezpieczeństwa w dzienniku błędów, ponieważ jest to znak, że ktoś coś przymierza.
Z którymkolwiek fragmentem kodu w OP ta sanityzacja nie byłaby możliwa.
Właściwie bardzo łatwo jest napisać małą stronę, która publikuje na stronie wszystko, co chcesz. Więc jeśli nie polegasz na wysyłaniu nagłówków stron odsyłających, zmienne pocztowe nie są bezpieczniejsze niż pobieranie zmiennych. Przypuszczam, że największą zaletą wyraźna $_POSTjest uniemożliwienie robotom wyszukiwarek ze robi coś takiego: thedailywtf.com/Articles/WellIntentioned-Destruction.aspx
Duroth
Nie powiedziałem nic przeciwnego. Powiedziałem, że jeśli formularz HTML używa POST, a skrypt obsługujący go otrzymuje dane formularza za pośrednictwem GET, skrypt chciałby o tym wiedzieć i nie wyrzucać tego faktu, jak to ma miejsce w przykładzie kobry. (Btw: strona odsyłająca też nie jest bezpieczna.)
1
Skorzystałbym $_POST, a $_GETponieważ inaczej na $_REQUESTich zawartość nie ma wpływu variables_order.
Kiedy używać $_POSTi $_GETzależy od rodzaju wykonywanej operacji. Operacja zmieniająca dane obsługiwane z serwera powinna być wykonywana przez żądanie POST, podczas gdy inne operacje powinny być wykonywane przez żądanie GET. Na przykład operacja, która usuwa konto użytkownika, nie powinna być wykonywana bezpośrednio po kliknięciu przez użytkownika łącza, podczas gdy przeglądanie obrazu można wykonać za pośrednictwem łącza.
instrukcja sprawdza, czy $ _REQUEST ma więcej niż jeden parametr (pierwszym parametrem w $ _REQUEST będzie adres Uri żądania, którego można użyć w razie potrzeby, niektóre pakiety PHP nie zwracają $ _GET, więc sprawdź, czy jest więcej niż 1 dla $ _GET, By domyślnie będzie to _POST $.
Optymalizujesz przedwcześnie. Ponadto, ze względów bezpieczeństwa, naprawdę powinieneś się zastanowić, czy GET powinien być używany do publikowania treści.
Proszę, nie próbuj mówić ludziom, że w POST jest coś bezpieczniejszego niż w GET.
Ja nie. Chodziło o to, że należy przemyśleć ich zastosowania i nie należy ich rażąco używać zamiennie, ponieważ „samo wpisanie REQUEST jest o wiele łatwiejsze”.
Alex Brasetvik
Jeśli masz na myśli to, że kobra powinna sprawdzić, czy dane zostały przesłane zgodnie z oczekiwaniami, to zgadzam się. Każdy z jego przykładów kodu uniemożliwia takie testowanie.
0
Jest brzydki i nie polecałbym go jako ostatecznego rozwiązania podczas wypychania kodu na żywo, ale podczas budowania funkcji reszt czasami przydatne jest posiadanie przechwytywacza parametrów `` catch-all '':
Ktoś mógłby prawdopodobnie dodać coś do tego, aby obsłużyć parametry wiersza poleceń lub cokolwiek pochodzi z twojego IDE. Gdy już zdecydujesz, co robi dana funkcja odpoczynku, możesz wybrać odpowiednią dla tego wywołania, aby upewnić się, że otrzymasz to, czego potrzebujesz do wersji wdrożeniowej. Zakłada się, że ustawiono „REQUEST_METHOD”.
!isset($_REQUEST['s'])
.Odpowiedzi:
$_REQUEST
Domyślnie zawiera zawartość$_GET
,$_POST
i$_COOKIE
.Ale to tylko wartość domyślna, która zależy od
variables_order
; i nie jesteś pewien, czy chcesz pracować z plikami cookie.Gdybym miał wybierać, pewnie bym nie używał
$_REQUEST
, a wybrałbym$_GET
lub$_POST
- w zależności od tego, co ma robić moja aplikacja (tj. Jedną lub drugą, ale nie obie) : ogólnie mówiąc:$_GET
gdy ktoś żąda danych z Twojej aplikacji.$_POST
gdy ktoś wypycha (wstawia, aktualizuje lub usuwa) dane do twojej aplikacji.Tak czy inaczej, nie będzie dużej różnicy w wydajności: różnica będzie znikoma w porównaniu z tym, co zrobi reszta twojego skryptu.
źródło
GET a POST
1) GET i POST tworzą tablicę (np. Array (klucz => wartość, klucz2 => wartość2, klucz3 => wartość3, ...)). Ta tablica zawiera pary klucz / wartość, gdzie klucze to nazwy kontrolek formularza, a wartości to dane wejściowe od użytkownika.
2) Zarówno GET, jak i POST są traktowane jako $ _GET i $ _POST. Są to superglobale, co oznacza, że są zawsze dostępne, niezależnie od zakresu - i można uzyskać do nich dostęp z dowolnej funkcji, klasy lub pliku bez konieczności wykonywania jakichkolwiek czynności specjalnych.
3) $ _GET to tablica zmiennych przekazywana do bieżącego skryptu przez parametry adresu URL.
4) $ _POST to tablica zmiennych przekazywana do bieżącego skryptu za pomocą metody HTTP POST.
Kiedy używać GET?
Informacje wysyłane z formularza metodą GET są widoczne dla każdego (wszystkie nazwy i wartości zmiennych wyświetlane są w adresie URL). GET ma również ograniczenia ilości wysyłanych informacji. Ograniczenie to około 2000 znaków. Ponieważ jednak zmienne są wyświetlane w adresie URL, można dodać stronę do zakładek. Może to być przydatne w niektórych przypadkach.
GET może służyć do wysyłania danych niewrażliwych.
Uwaga: GET NIGDY nie powinien być używany do wysyłania haseł lub innych poufnych informacji!
Kiedy używać POST?
Informacje wysyłane z formularza metodą POST są niewidoczne dla innych (wszystkie nazwy / wartości są osadzone w treści żądania HTTP) i nie mają ograniczeń co do ilości wysyłanych informacji.
Ponadto POST obsługuje zaawansowane funkcje, takie jak obsługa wieloczęściowego wejścia binarnego podczas przesyłania plików na serwer.
Jednak ponieważ zmienne nie są wyświetlane w adresie URL, nie można dodać strony do zakładek.
źródło
źródło
GET
z ciągu zapytania,POST
z przesłania formularza).Sugerowałbym użycie
$_POST
i$_GET
wyraźnie.Używanie $ _REQUEST powinno i tak być niepotrzebne przy odpowiednim zaprojektowaniu witryny, a ma pewne wady, takie jak pozostawienie cię otwartego na łatwiejsze
CSRF/XSS
ataki i inne głupoty wynikające z przechowywania danych w adresie URL.Różnica prędkości w obu przypadkach powinna być minimalna.
źródło
Użyj REQUEST. Nikt nie dba o szybkość tak prostej operacji, a jest to znacznie czystszy kod.
źródło
$_REQUEST
jest złym wnioskiem. Zobacz moją odpowiedź.Nie martw się. Ale nadal powinieneś używać drugiego rozwiązania (plus dodatkowe sprawdzenie, czy żadna z tych zmiennych nie istnieje), ponieważ występują problemy z bezpieczeństwem
$_REQUEST
(ponieważ$_GET
i$_POST
nie są jedynymi źródłami dla tej tablicy).Wydaje mi się, że pojawił się post o problemach z
$_REQUEST
wczoraj. Pozwól mi to znaleźć.EDYCJA : No cóż, nie bezpośrednio post, ale tutaj jest tak: http://kuza55.blogspot.com/2006/03/request-variable-fixation.html
źródło
Użyj tego, ponieważ jest bezpieczniejszy i nie spowoduje zauważalnej różnicy prędkości
źródło
$_REQUEST
ale nadal umożliwia dostęp do tego samego skryptu w obie strony (w moim przypadku ten sam skrypt jest używany z różnymi 'akcjami' i czasami $ _GET byłoby w porządku, ale innym razem potrzebuję $ _POST, aby ukryć / zabezpieczyć dane).Istnieją pewne obawy związane z bezpieczeństwem, ponieważ haker może ustawić plik cookie, który zastąpi wartość $ _POST lub $ _GET. Jeśli masz do czynienia z poufnymi danymi, nie polecam używania $ _REQUEST. - Xandor
nie można użyć
$_GET
alternatywy$_POST
w niektórych przypadkach.Kiedy ??
GET
ma również ograniczenia dotyczące ilości przesyłanych informacji. Ograniczenie to około 2000 znaków.Inną rzeczą jest to, że jest kilka przypadków, w których nie można odzyskać danych za pomocą
$_POST
Kiedy ?
Do usługi odpoczynku
nie ma nic złego w użyciu
$_REQUEST
.Ale sposobem na to jest jawne sprawdzenie $ _SERVER ['REQUEST_METHOD'], a nie poleganie na tym, że $ _POST jest puste dla GET.
źródło
$_SERVER['REQUEST_METHOD']
do sprawdzania, czy skrypt zostanie wywołany z którymkolwiek z nich. Ale stwierdzenie, że nic się nie dzieje,$_REQUEST
nie jest w 100% prawdziwe. Istnieją pewne obawy dotyczące bezpieczeństwa, ponieważ haker może ustawić plik cookie, który zastąpi wartość $ _POST lub $ _GET. Jeśli masz do czynienia z poufnymi danymi, nie polecam używania$_REQUEST
.$ _GET pobiera zmienne z zapytania lub adresu URL.>
$ _POST pobiera zmienne z metody POST, takie jak (ogólnie) formularze.
$ _REQUEST jest połączeniem $ _GET i $ _POST, gdzie $ _POST zastępuje $ _GET. Dobrze jest używać $ _REQUEST na formularzach referencyjnych do walidacji.
źródło
request_order
wartości plików cookie i może również zawierać wartości cookie, dlatego nie jest to bardzo niezawodna ani użyteczna funkcja.Użyłbym drugiej metody, ponieważ jest bardziej wyraźna. W przeciwnym razie nie wiesz, skąd pochodzą zmienne.
Dlaczego mimo wszystko musisz sprawdzić zarówno GET, jak i POST? Z pewnością użycie jednego lub drugiego ma więcej sensu.
źródło
GET
użyciem tylko jednego elementu (np. Przenoszenie go) iPOST
wielu z nich (formularz z polami wyboru ...).Zawsze używam tylko _GET lub _POST. Wolę mieć kontrolę.
To, co mi się nie podoba w żadnym fragmencie kodu w OP, to to, że odrzucają informacje o tym, która metoda HTTP została użyta. Ta informacja jest ważna dla oczyszczania wkładu.
Na przykład, jeśli skrypt akceptuje dane z formularza, który ma zostać wprowadzony do bazy danych, formularz powinien lepiej używać POST ( używaj GET tylko dla idempotentnych akcji ). Ale jeśli skrypt otrzymuje dane wejściowe metodą GET, to powinien (normalnie) zostać odrzucony. Dla mnie taka sytuacja może uzasadniać zapisanie naruszenia bezpieczeństwa w dzienniku błędów, ponieważ jest to znak, że ktoś coś przymierza.
Z którymkolwiek fragmentem kodu w OP ta sanityzacja nie byłaby możliwa.
źródło
$_POST
jest uniemożliwienie robotom wyszukiwarek ze robi coś takiego: thedailywtf.com/Articles/WellIntentioned-Destruction.aspxSkorzystałbym
$_POST
, a$_GET
ponieważ inaczej na$_REQUEST
ich zawartość nie ma wpływuvariables_order
.Kiedy używać
$_POST
i$_GET
zależy od rodzaju wykonywanej operacji. Operacja zmieniająca dane obsługiwane z serwera powinna być wykonywana przez żądanie POST, podczas gdy inne operacje powinny być wykonywane przez żądanie GET. Na przykład operacja, która usuwa konto użytkownika, nie powinna być wykonywana bezpośrednio po kliknięciu przez użytkownika łącza, podczas gdy przeglądanie obrazu można wykonać za pośrednictwem łącza.źródło
Używam tego,
instrukcja sprawdza, czy $ _REQUEST ma więcej niż jeden parametr (pierwszym parametrem w $ _REQUEST będzie adres Uri żądania, którego można użyć w razie potrzeby, niektóre pakiety PHP nie zwracają $ _GET, więc sprawdź, czy jest więcej niż 1 dla $ _GET, By domyślnie będzie to _POST $.
źródło
Optymalizujesz przedwcześnie. Ponadto, ze względów bezpieczeństwa, naprawdę powinieneś się zastanowić, czy GET powinien być używany do publikowania treści.
źródło
Jest brzydki i nie polecałbym go jako ostatecznego rozwiązania podczas wypychania kodu na żywo, ale podczas budowania funkcji reszt czasami przydatne jest posiadanie przechwytywacza parametrów `` catch-all '':
Ktoś mógłby prawdopodobnie dodać coś do tego, aby obsłużyć parametry wiersza poleceń lub cokolwiek pochodzi z twojego IDE. Gdy już zdecydujesz, co robi dana funkcja odpoczynku, możesz wybrać odpowiednią dla tego wywołania, aby upewnić się, że otrzymasz to, czego potrzebujesz do wersji wdrożeniowej. Zakłada się, że ustawiono „REQUEST_METHOD”.
źródło