HTTP definiuje różne sposoby interakcji z serwerem i istnieją 4 podstawowe metody: GET, POST, PUT i DELETE. Pełna nazwa URL to deskryptor zasobu, możemy to nazwać tak: adres URL, używany do opisu zasobu w sieci, a GET, POST, PUT, DELETE w HTTP odpowiada czterem operacjom: sprawdzaniu, modyfikowaniu, dodawaniu i usuwaniu tego zasobu. Na tym etapie powinieneś mieć ogólne zrozumienie, że GET jest zazwyczaj używany do pozyskiwania/zapytywania informacji o zasobach, podczas gdy POST służy do aktualizacji informacji o zasobach.
1. Zgodnie ze specyfikacją HTTP, GET służy do wyszukiwania informacji i powinien być bezpieczny oraz idempotencjalny.
(1). Tak zwane bezpieczeństwo oznacza, że operacja służy do pozyskiwania informacji, a nie ich modyfikacji. Innymi słowy, prośby GET zazwyczaj nie powinny mieć skutków ubocznych. To znaczy, że pobiera jedynie informacje o zasobach, podobnie jak zapytanie bazy danych, i nie będzie modyfikować, dodawać danych ani wpływać na stan zasobu.
* Uwaga: Znaczenie bezpieczeństwa odnosi się tutaj wyłącznie do informacji niemodyfikowanych.
(2). idempotent oznacza, że wiele żądań do tego samego adresu URL powinno zwracać ten sam wynik.
Jednak w praktyce powyższe dwa przepisy nie są tak rygorystyczne. Przykłady cytowania artykułów innych osób: Na przykład strona główna serwisu informacyjnego jest stale aktualizowana. Chociaż drugie żądanie zwraca inną partię wiadomości, operacja jest nadal uważana za bezpieczną i idempotentną, ponieważ zawsze zwraca aktualne wiadomości. Zasadniczo, jeśli celem jest, aby użytkownik otwierając link mógł być pewien, że zasób nie został zmieniony z jego punktu widzenia.
2. Zgodnie ze specyfikacją HTTP, POST reprezentuje żądanie, które może modyfikować zasób na serwerze. Kontynuując powyższy przykład: Wciąż wiadomości Weźmy na przykład stronę internetową, czytelnicy powinni zamieszczać własne komentarze na temat wiadomości, ponieważ zasoby strony różnią się po przesłaniu komentarza lub modyfikacji zasobów.
Powyższe mniej więcej omawia niektóre zasady GET i POST zawarte w specyfikacji HTTP. Jednak wiele osób nie stosuje się do specyfikacji HTTP podczas faktycznego wykonywania tego zadania, co może prowadzić do wielu przyczyn tego problemu, takich jak:
1. Wiele osób używa GET do aktualizacji zasobów, ponieważ muszą wejść do FORM, aby użyć POST, co może być trochę kłopotliwe.
2. Operacje dodawania, usuwania, modyfikowania i sprawdzania zasobów można faktycznie wykonać za pomocą GET/POST, bez konieczności używania PUT i DELETE.
3. Kolejnym problemem jest to, że wczesni projektanci frameworków Web MVC nie traktowali i nie projektowali URL-i świadomie jako abstrakcyjnych zasobów, więc poważnym problemem jest to, że tradycyjny framework Web MVC obsługuje zasadniczo tylko dwie metody HTTP, GET i POST, ale nie obsługuje metod PUT i DETETE.
* Krótkie wyjaśnienie MVC: MVC pierwotnie istniało w programie Desktop, M odnosi się do modelu danych, V do interfejsu użytkownika, a C do kontrolera. Celem użycia MVC jest rozdzielenie kodu implementacyjnego M i V, tak aby ten sam program mógł używać różnych reprezentacji.
Powyższe 3 punkty zazwyczaj opisują stary styl (bez ścisłego przestrzegania specyfikacji HTTP), a wraz z rozwojem architektury pojawił się REST (Representational State Transfer), nowy styl wspierający specyfikację HTTP.
Po omówieniu problemu podstawowego, przyjrzyjmy się różnicy między GET a POST względem zjawiska powierzchniowego:
1. Dane żądania GET będą dołączone do adresu URL (czyli dane umieszczone w nagłówku protokołu HTTP), a ? Podziel adres URL i prześlij dane, a parametry są powiązane przez &, na przykład: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Jeśli dane to angielskie litery/cyfry, wyślij je tak, jak są, jeśli jest spacja, przekonwertuj je na +, jeśli są to znaki chińskie/inne, następnie bezpośrednio zaszyfruj ciąg znaków BASE64, aby uzyskać próbkę taką: %E4%BD%A0%E5%A5%BD, gdzie XX w %XX to ASCII reprezentowane przez symbol w systemie szesnastkowym.
POST umieszcza przesłane dane w korpusie pakietu HTTP.
2. "Maksymalna ilość danych przesyłanych metodą GET może wynosić tylko 1024 bajty, teoretycznie nie ma ograniczenia POST, a duża ilość danych może być przesyłana, do 80KB w IIS4 i 100KB w IIS5"??!
Powyższe zdanie zostało przekierowane z innych artykułów, w rzeczywistości jest błędne i nieprecyzyjne stwierdzenie tego:
(1). Po pierwsze, "dane przesyłane metodą GET mogą mieć maksymalnie 1024 bajty", ponieważ GET przesyła dane przez URL, więc ilość danych, które GET może przesłać, jest bezpośrednio związana z długością URL. W rzeczywistości nie ma górnego limitu parametrów dla URL, a specyfikacja protokołu HTTP nie ogranicza długości URL. To ograniczenie jest narzucone przez konkretną przeglądarkę i serwer. Limit długości URL w IE wynosi 2083 bajty (2K+35). W przypadku innych przeglądarek, takich jak Netscape, FireFox itp., nie ma teoretycznego limitu długości, a jego limit zależy od wsparcia systemu operacyjnego.
Zwróć uwagę, że ogranicza to całą długość URL, a nie tylko wartość parametru, długość danych. [Zobacz Ref. 5]
(2). Teoretycznie POST nie ma limitu rozmiaru, specyfikacja protokołu HTTP go nie obowiązuje, i niedokładne jest twierdzenie, że "istnieje limit rozmiaru 80K/100K dla danych POST", nie ma ograniczenia dla danych POST, a to moc obliczeniowa obsługi serwera odgrywa rolę ograniczającą.
W przypadku programów ASP obiekt Request ma limit długości danych do 100K podczas przetwarzania każdego pola formularza. Ale w przypadku Request.BinaryRead nie ma takiego ograniczenia.
Na podstawie tego, dla IIS 6.0 Microsoft zaostrzył ograniczenia ze względów bezpieczeństwa. Musimy także zwrócić uwagę na:
1). IIS 6.0 domyślnie stosuje maksymalnie 200 KB danych ASP POST, a limit wynosi 100 KB na pole formularza.
2). Domyślny rozmiar plików uploadu w IIS 6.0 to 4MB.
3). IIS 6.0 domyślnie przyjmuje maksymalny nagłówek żądania 16KB.
Te ograniczenia nie były dostępne przed IIS 6.0. [Zobacz Ref. 5]
Więc powyższe 80K i 100K mogą być po prostu domyślnymi wartościami (uwaga: jeszcze nie potwierdziłem parametrów IIS4 i IIS5), ale zdecydowanie możesz je ustawić samodzielnie. Ponieważ domyślne wartości tych parametrów różnią się w każdej wersji IIS, prosimy o zapoznanie się z odpowiednim dokumentem konfiguracyjnym IIS, aby uzyskać szczegóły.
3. W ASP serwer używa Request.QueryString do uzyskania parametru GET request oraz Request.Form do uzyskania parametru POST request. W JSP użyj request.getParameter(\"XXXX\"), aby go uzyskać, chociaż istnieje także metoda request.getQueryString() w jsp, ale jest ona bardziej uciążliwa, na przykład: wyślij test.jsp?name=hyddd&password=hyddd, a następnie użyj request.getQueryString(), aby uzyskać :name= hyddd&password=hyddd。 W PHP możesz użyć _GET i _POST $ do pobierania danych odpowiednio z GET i POST, natomiast $_REQUEST może pobierać dane zarówno z żądań GET, jak i POST. Warto zauważyć, że użycie request w JSP i $_REQUEST w PHP wiąże się z ukryciami, co zostanie podsumowane w artykule następnym razem.
4.POST jest bezpieczniejsze niż GET. Uwaga: Wspomniane tutaj zabezpieczenie nie jest tym samym pojęciem co "bezpieczeństwo" opisane w powyższym GET. Na przykład, jeśli przesłasz dane przez GET, twoja nazwa użytkownika i hasło pojawią się w formie jawnej na adresie URL, ponieważ (1) strona logowania może być buforowana przez przeglądarkę, (2) inni będą przeglądać historię przeglądarki, dzięki czemu inni mogą uzyskać twoje konto i hasło Atak fałszerstwa.
Podsumowując, Get to żądanie żądania danych z serwera, podczas gdy Post to żądanie przesłania danych na serwer, w FORM metoda domyślnie przyjmuje "GET", w zasadzie GET i POST to po prostu różne mechanizmy wysyłania, nie jeden przyjmuje i wysyła jeden!
|
Opublikowano 06.12.2014 10:54:55
|
|
|
Opublikowano 07.12.2014 17:24:18
