GET vs. POST

HTTP POCZTA Żądania dostarczają dodatkowe dane od klienta (przeglądarki) do serwera w treści wiadomości. W przeciwieństwie, OTRZYMAĆ żądania zawierają wszystkie wymagane dane w adresie URL. Formularze w HTML mogą korzystać z dowolnej metody, określając method = „POST” lub method = „GET” (domyślnie) w element. Określona metoda określa sposób przesyłania danych formularza na serwer. Gdy metoda ma wartość GET, wszystkie dane formularza są kodowane w adresie URL, dołączanym do akcja URL jako parametry ciągu zapytania. W przypadku POST dane formularza pojawiają się w treści wiadomości żądania HTTP.

Wykres porównania

Tabela porównawcza GET a POST

	OTRZYMAĆ	POCZTA

Historia	Parametry pozostają w historii przeglądarki, ponieważ są częścią adresu URL	Parametry nie są zapisywane w historii przeglądarki.
Zakładka	Można dodać do zakładek.	Nie można dodać do zakładek.
Przycisk POWRÓT / zachowanie ponownego przesłania	Żądania GET są ponownie wykonywane, ale nie mogą być ponownie przesyłane na serwer, jeśli HTML jest przechowywany w pamięci podręcznej przeglądarki.	Przeglądarka zwykle ostrzega użytkownika, że dane będą musiały zostać ponownie przesłane.
Typ kodowania (atrybut enctype)	application / x-www-form-urlencoded	multipart / form-data or application / x-www-form-urlencoded Użyj kodowania wieloczęściowego dla danych binarnych.
Parametry	możemy wysłać, ale dane parametrów są ograniczone do tego, co możemy włożyć do wiersza żądania (URL). Najbezpieczniejsze w użyciu mniej niż 2 KB parametrów, niektóre serwery obsługują do 64 KB	Może wysyłać parametry, w tym przesyłanie plików, na serwer.
Zhakowany	Łatwiej zhackować dzieciaki ze scenariusza	Trudniejsze do zhakowania
Ograniczenia dotyczące typu danych formularza	Tak, dozwolone są tylko znaki ASCII.	Bez ograniczeń. Dane binarne są również dozwolone.
Bezpieczeństwo	GET jest mniej bezpieczny w porównaniu do POST, ponieważ przesłane dane są częścią adresu URL. Jest to zapisywane w historii przeglądarki i dziennikach serwera w postaci zwykłego tekstu.	POST jest trochę bezpieczniejszy niż GET, ponieważ parametry nie są przechowywane w historii przeglądarki lub w dziennikach serwera WWW.
Ograniczenia dotyczące długości danych formularza	Tak, ponieważ dane formularza znajdują się w adresie URL, a długość adresu URL jest ograniczona. Bezpieczny limit długości adresu URL wynosi często 2048 znaków, ale różni się w zależności od przeglądarki i serwera WWW.	Bez ograniczeń
Użyteczność	Nie należy stosować metody GET podczas wysyłania haseł lub innych poufnych informacji.	Metoda POST używana podczas wysyłania haseł lub innych poufnych informacji.
Widoczność	Metoda GET jest widoczna dla wszystkich (będzie wyświetlana w pasku adresu przeglądarki) i ma ograniczenia dotyczące ilości wysyłanych informacji.	Zmienne metody POST nie są wyświetlane w adresie URL.
Buforowane	Można buforować	Nie buforowane

Zawartość: GET vs POST

1 Różnice w składaniu formularzy
- 1.1 Plusy i minusy
2 różnice w przetwarzaniu po stronie serwera
3 Zalecane użycie
4 Co z HTTPS?
5 referencji

Różnice w składaniu formularzy

Podstawowa różnica między METODA = „POBIERZ” i METODA = „POST” jest to, że odpowiadają różne żądania HTTP, zgodnie ze specyfikacją HTTP. Proces przesyłania dla obu metod rozpoczyna się w ten sam sposób - zestaw danych formularza jest konstruowany przez przeglądarkę, a następnie kodowany w sposób określony przez typ atrybut. Dla METODA = „POST typ atrybut może być multipart / form-data lub application / x-www-form-urlencoded, podczas gdy dla METODA = „POBIERZ”, tylko application / x-www-form-urlencoded jest dozwolone. Ten zestaw danych formularza jest następnie przesyłany do serwera.

W przypadku przesyłania formularza za pomocą METHOD = "GET" przeglądarka konstruuje adres URL, przyjmując wartość parametru akcja atrybut, dołączając a ? do niego, a następnie dołączenie zestawu danych formularza (zakodowanego przy użyciu typu treści application / x-www-form-urlencoded). Przeglądarka przetwarza ten adres URL tak, jakby podążał za linkiem (lub tak, jakby użytkownik wpisał adres URL bezpośrednio). Przeglądarka dzieli adres URL na części i rozpoznaje hosta, a następnie wysyła do tego hosta żądanie GET z resztą adresu URL jako argumentem. Serwer bierze to stamtąd. Należy pamiętać, że ten proces oznacza, że dane formularza są ograniczone do kodów ASCII. Szczególną uwagę należy zwrócić na kodowanie i dekodowanie innych typów znaków podczas przekazywania ich przez adres URL w formacie ASCII.

Przesłanie formularza METHOD = „POST” powoduje wysłanie żądania POST przy użyciu wartości akcja atrybut i komunikat utworzony zgodnie z typem treści określonym przez typ atrybut.

Plusy i minusy

Ponieważ dane formularza są wysyłane jako część adresu URL, kiedy OTRZYMAĆ Jest używane --

Dane formularza są ograniczone do kodów ASCII. Szczególną uwagę należy zwrócić na kodowanie i dekodowanie innych typów znaków podczas przekazywania ich przez adres URL w formacie ASCII. Z drugiej strony można przesyłać dane binarne, obrazy i inne pliki METODA = „POST”
Wszystkie wypełnione dane formularza są widoczne w adresie URL. Co więcej, jest również przechowywany w historii przeglądania / logach użytkownika w przeglądarce. Te problemy sprawiają OTRZYMAĆ Mniej bezpieczne.
Jednak jedną z zalet przesyłania danych formularzy jako części adresu URL jest to, że można dodawać do zakładek adresy URL i bezpośrednio z nich korzystać oraz całkowicie ominąć proces wypełniania formularza.
Istnieje ograniczenie ilości danych formularza, które można wysłać, ponieważ długości adresów URL są ograniczone.
Skrypciarze mogą łatwiej ujawnić luki w zabezpieczeniach systemu, aby je zhakować. Na przykład włamano się do Citibank, zmieniając numery kont w ciągu adresu URL.^[1] Oczywiście doświadczeni hakerzy lub twórcy stron internetowych mogą ujawnić takie podatności, nawet jeśli używany jest test POST; to tylko trochę trudniejsze. Zasadniczo serwer musi być podejrzany w stosunku do wszelkich danych wysyłanych przez klienta i chronić się przed niezabezpieczonymi bezpośrednimi referencjami obiektów.

Różnice w przetwarzaniu po stronie serwera

Zasadniczo przetwarzanie przesłanych danych formularza zależy od tego, czy są one przesyłane METODA = „POBIERZ” lub METODA = „POST”. Ponieważ dane są kodowane na różne sposoby, potrzebne są różne mechanizmy dekodowania. Zatem ogólnie mówiąc, zmiana METODY może wymagać zmiany skryptu, który przetwarza przesłanie. Na przykład, gdy używany jest interfejs CGI, skrypt odbiera dane w zmiennej środowiskowej (QUERYSTRING), kiedy OTRZYMAĆ Jest używane. Ale kiedy POCZTA jest używany, dane formularza są przekazywane w standardowym strumieniu wejściowym (standardowe), a liczba bajtów do odczytania jest podana w nagłówku Content-length.

Zalecane użycie

Polecenie GET jest zalecane przy przesyłaniu formularzy „idempotentnych” - tych, które „nie zmieniają znacząco stanu świata”. Innymi słowy, formularze obejmujące tylko zapytania do bazy danych. Inna perspektywa polega na tym, że kilka idempotentnych zapytań będzie miało taki sam efekt jak jedno zapytanie. W przypadku aktualizacji bazy danych lub innych działań, takich jak uruchamianie wiadomości e-mail, zalecane jest użycie testu POST.

Z bloga programisty Dropbox:

przeglądarka nie wie dokładnie, co robi konkretny formularz HTML, ale jeśli formularz zostanie przesłany przez HTTP GET, przeglądarka wie, że bezpieczne jest automatyczne ponowienie próby przesłania, jeśli wystąpi błąd sieci. W przypadku formularzy korzystających z protokołu HTTP POST ponowna próba może nie być bezpieczna, dlatego przeglądarka najpierw prosi użytkownika o potwierdzenie.

Żądanie „GET” jest często buforowalne, podczas gdy żądanie „POST” jest trudne. W przypadku systemów zapytań może to mieć znaczący wpływ na wydajność, szczególnie jeśli ciągi zapytań są proste, ponieważ pamięci podręczne mogą obsługiwać najczęstsze zapytania.

W niektórych przypadkach przy użyciu POCZTA jest zalecane nawet w przypadku idempotentnych zapytań:

Jeśli dane formularza zawierałyby znaki inne niż ASCII (takie jak znaki akcentowane) METODA = „POBIERZ” co do zasady nie ma zastosowania, chociaż może działać w praktyce (głównie w przypadku znaków ISO Latin 1).
Jeśli zestaw danych formularza jest duży - powiedzmy, setki znaków - wtedy METODA = „POBIERZ” może powodować praktyczne problemy z implementacjami, które nie obsługują tak długich adresów URL.
Możesz tego uniknąć METODA = „POBIERZ” aby uczynić go mniej widocznym dla użytkowników, jak działa formularz, szczególnie w celu uczynienia „ukrytych” pól (INPUT TYPE = „HIDDEN”) bardziej ukrytymi, ponieważ nie pojawiają się w adresie URL. Ale nawet jeśli używasz ukrytych pól z METODA = „POST”, nadal będą się pojawiać w kodzie źródłowym HTML.

Co z HTTPS?

Zaktualizowano 15 maja 2015 r.: W szczególności podczas korzystania z HTTPS (HTTP przez TLS / SSL), POST oferuje więcej bezpieczeństwa niż GET?

To interesujące pytanie. Załóżmy, że przesyłasz żądanie GET do strony internetowej:

 GET https://www.example.com/login.php?user=mickey&passwd=mini

Zakładając, że twoje połączenie internetowe jest monitorowane, jakie informacje o tym żądaniu będą dostępne dla snoopera? Jeśli zamiast tego zostanie użyty POST, a dane użytkownika i hasła zostaną uwzględnione w zmiennych POST, czy będzie to bardziej bezpieczne w przypadku połączeń HTTPS?

Odpowiedź brzmi nie. Jeśli zgłosisz takie żądanie GET, atakujący monitorujący ruch internetowy będzie znać tylko następujące informacje:

Fakt, że nawiązałeś połączenie HTTPS
Nazwa hosta - www.example.com
Całkowita długość żądania
Długość odpowiedzi

Część ścieżki adresu URL - tzn. Żądana strona, a także parametry ciągu zapytania - są chronione (szyfrowane), gdy są „za pośrednictwem drutu”, tj. W drodze do serwera docelowego. Sytuacja jest dokładnie taka sama w przypadku żądań POST.

Oczywiście serwery sieciowe rejestrują cały URL w postaci zwykłego tekstu w dziennikach dostępu; więc wysyłanie poufnych informacji przez GET nie jest dobrym pomysłem. Dotyczy to niezależnie od tego, czy używany jest protokół HTTP czy HTTPS.

Bibliografia

wikipedia: POST (HTTP)
Metody żądania HTTP
HTTP Post - W3.org
HTTP Get - W3.org
Czy HTTPS ukrywa dostępne adresy URL? - Wymiana stosu

Technologia