According to the HTTP specification, you should use the POST method when you're using the form to change the state of something on the server end. For example, if a page has a form to allow users to add their own comments, like this page here, the form should use POST. If you click "Reload" or "Refresh" on a page that you reached through a POST, it's almost always an error -- you shouldn't be posting the same comment twice -- which is why these pages aren't bookmarked or cached.
You should use the GET method when your form is, well, getting something off the server and not actually changing anything. For example, the form for a search engine should use GET, since searching a Web site should not be changing anything that the client might care about, and bookmarking or caching the results of a search-engine query is just as useful as bookmarking or caching a static HTML page.
Obsługa formularzy
Jedną z najpotężniejszych możliwości PHP jest sposób, w jaki obsługuje formularze. Podstawową rzecza, którą trzeba zrozumieć jest fakt że każdy element formularza będzie automatycznie dostępny dla Twoich skryptów PHP. Przeczytaj rozdział Zmienne z zewnętrznych źródeł zawierający więcej informacji i przykładów użycia formularzy z PHP. Mamy tutaj przykładowy formularz HTML:
Przykład #1 Prosty formularz PHP
<form action="action.php" method="post"> <p>Imię: <input type="text" name="imie" /></p> <p>Wiek: <input type="text" name="wiek" /></p> <p><input type="submit" /></p> </form>
Nie ma w nim nic szczególnego. To zwyczajny formularz HTML bez żadnych specjalnych tagów. Kiedy użytkownik wypełni ten formularz i naciśnie przycisk wysyłający, zostanie wywołana strona action.php. W tym pliku będziesz musiał napisać coś w tym stylu::
Przykład #2 Wyświetlanie danych z naszego formularza
HCześć<?php echo htmlspecialchars($_POST['nazwa']); ?>.
Masz <?php echo (int)$_POST['wiek']; ?> lat.
Przykładowym wynikiem działania tego skryptu może być:
Cześć Robert. Masz 25 lat.
Pomijając htmlspecialchars() i (int), wszystko powinno być jasne. htmlspecialchars() zapewnia, że wszystkie znaki, które mają specjalne znaczenie w HTML zostaną poprawnie zakodowane, więc użytkownicy nie będą mogli wstrzyknąć tagów HTML lub JavaScriptu na Twoją stronę. Pole wiek, ponieważ wiemy że jest to liczba, możemy przekonwertować je na typ integer, co również zaowocuje pozbyciem się wszystkich niepotrzebnych znaków. Możesz też zadbać aby PHP robiło to automatycznie używając rozszerzenia filter. Zmienne $_POST['imie'] i $_POST['wiek'] są automatycznie tworzone przez PHP. Wcześniej używaliśmy superglobalnej $_SERVER; powyżej właśnie wprowadziliśmy $_POST, która zawiera wszystkie dane wysłane żądaniem POST. Zauważ że method naszego formularza została ustawiona na POST. Jeśli użylibysmy metody GET to informacje z formularza znalazłyby się w superglobalnej $_GET. Możesz też użyć superglobalnej $_REQUEST, jeśli nie zwracasz uwagi na źródło pochodzenia danych. Zawiera ona polączone informacje na temat danych GET, POST i COOKIE.
W PHP możesz też obsługiwać formularze XForms, aczkolwiek za jakiś czas poczujesz się komfortowo pracując z ogólnie wspieranymi formularzami HTML. Mimo iż praca z formularzami XForms nie jest dla początkujących, możesz być tym zainteresowany. Mamy też krótkie wprowadzenie do obsługi danych z XForms w sekcji poświęconej możliwościom PHP.
add a note
User Contributed Notes 3 notes
sethg at ropine dot com ¶
20 years ago
Johann Gomes (johanngomes at gmail dot com) ¶
13 years ago
Also, don't ever use GET method in a form that capture passwords and other things that are meant to be hidden.
nucc1 ¶
6 years ago
worth clarifying:
POST is not more secure than GET.
The reasons for choosing GET vs POST involve various factors such as intent of the request (are you "submitting" information?), the size of the request (there are limits to how long a URL can be, and GET parameters are sent in the URL), and how easily you want the Action to be shareable -- Example, Google Searches are GET because it makes it easy to copy and share the search query with someone else simply by sharing the URL.
Security is only a consideration here due to the fact that a GET is easier to share than a POST. Example: you don't want a password to be sent by GET, because the user might share the resulting URL and inadvertently expose their password.
However, a GET and a POST are equally easy to intercept by a well-placed malicious person if you don't deploy TLS/SSL to protect the network connection itself.
All Forms sent over HTTP (usually port 80) are insecure, and today (2017), there aren't many good reasons for a public website to not be using HTTPS (which is basically HTTP + Transport Layer Security).
As a bonus, if you use TLS you minimise the risk of your users getting code (ADs) injected into your traffic that wasn't put there by you.
