HTTP definieert verschillende manieren om met de server te communiceren, en er zijn 4 basismethoden, namelijk GET, POST, PUT en DELETE. De volledige naam van de URL is een resource descriptor, we kunnen het als volgt zien: een URL-adres, het wordt gebruikt om een resource op een netwerk te beschrijven, en GET, POST, PUT, DELETE in HTTP komt overeen met de vier bewerkingen van controleren, wijzigen, toevoegen en verwijderen van deze resource. Op dit punt zou je een algemeen begrip moeten hebben: GET wordt meestal gebruikt om broninformatie te verkrijgen of op te vragen, terwijl POST meestal wordt gebruikt om broninformatie bij te werken.
1. Volgens de HTTP-specificatie wordt GET gebruikt voor informatieopvraging en moet het veilig en idempotent zijn.
(1). De zogenaamde beveiliging betekent dat de operatie wordt gebruikt om informatie te verkrijgen in plaats van deze te wijzigen. Met andere woorden, GET-verzoeken zouden over het algemeen geen bijwerkingen moeten hebben. Dat wil zeggen, het verkrijgt alleen resource-informatie, net als databasequery, en zal geen gegevens wijzigen, toevoegen of de status van de bron beïnvloeden.
* Opmerking: De betekenis van beveiliging verwijst hier alleen naar niet-gewijzigde informatie.
(2). Idempotent betekent dat meerdere verzoeken naar dezelfde URL hetzelfde resultaat moeten opleveren.
In de praktijk zijn de bovenstaande twee regels echter niet zo streng. Voorbeelden van het citeren van artikelen van anderen: bijvoorbeeld, de voorpagina van een nieuwssite wordt voortdurend bijgewerkt. Hoewel het tweede verzoek een andere reeks nieuws teruggeeft, wordt de operatie nog steeds als veilig en idempotent beschouwd omdat het altijd het actuele nieuws teruggeeft. Fundamenteel, als het doel is dat een gebruiker bij het openen van een link er vanuit zijn perspectief op kan vertrouwen dat de bron niet is veranderd.
2. Volgens de HTTP-specificatie vertegenwoordigt POST een verzoek dat een resource op de server kan wijzigen. Verder met het bovenstaande voorbeeld: Still news Neem de website als voorbeeld, lezers moeten hun eigen reacties op het nieuws plaatsen, omdat de bronnen van de site anders zijn nadat de reactie is ingediend of de bronnen zijn aangepast.
Bovenstaande bespreekt grofweg enkele principes van GET en POST in de HTTP-specificatie. Veel mensen volgen echter de HTTP-specificatie niet wanneer ze het daadwerkelijk doen, wat tot veel redenen voor dit probleem kan leiden, zoals:
1. Veel mensen gebruiken GET om bronnen bij te werken omdat ze naar FORM moeten gaan om POST te gebruiken, wat wat lastig zal zijn.
2. De operatie van toevoegen, verwijderen, wijzigen en controleren van bronnen kan daadwerkelijk worden uitgevoerd via GET/POST, zonder dat PUT en DELETE nodig zijn.
3. Een andere is dat vroege ontwerpers van Web MVC-frameworks URL's niet bewust als abstracte bronnen behandelden en ontwierpen, waardoor een serieus probleem is dat het traditionele Web MVC-framework in feite slechts twee HTTP-methoden ondersteunt, GET en POST, maar geen PUT- en DELETE-methoden.
* Een korte uitleg van MVC: MVC bestond oorspronkelijk in het Desktop-programma, M verwijst naar het datamodel, V naar de gebruikersinterface en C naar de controller. Het doel van het gebruik van MVC is om de implementatiecode van M en V te scheiden, zodat hetzelfde programma verschillende representaties kan gebruiken.
De bovenstaande drie punten beschrijven doorgaans de oude stijl (zonder strikte naleving van de HTTP-specificatie), met de ontwikkeling van de architectuur is er nu REST (Representational State Transfer), een nieuwe stijl die de HTTP-specificatie ondersteunt.
Na het bespreken van het hoofdprobleem, laten we kijken naar het verschil tussen GET en POST vanuit het oppervlaktefenomeen:
1. De gegevens van het GET-verzoek worden gekoppeld aan de URL (dat wil zeggen, de data wordt in de HTTP-protocolheader geplaatst), en de ? Splits de URL en verzend de gegevens, en de parameters worden verbonden met &, bijvoorbeeld: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Als de data Engelse letters/cijfers zijn, stuur het dan zoals het is; als het een spatie is, zet het om naar +, als het Chinees/andere tekens zijn, en versleutel dan direct de string met BASE64 om een voorbeeld te krijgen zoals: %E4%BD%A0%E5%A5%BD, waarbij XX in %XX de ASCII is die wordt weergegeven door het symbool in hexadecimaal.
POST plaatst de ingediende gegevens in het pakketlichaam van het HTTP-pakket.
2. "De maximale data die door de GET-methode wordt verzonden kan slechts 1024 bytes zijn, theoretisch is er geen limiet aan POST, en een grote hoeveelheid data kan worden overgedragen, tot 80KB in IIS4 en 100KB in IIS5"??!
De bovenstaande zin is omgeleid van andere artikelen, in feite is het onjuist en onjuist om dit te zeggen:
(1). Allereerst "de gegevens die door de GET-methode worden verzonden kunnen maximaal 1024 bytes zijn", omdat GET data via de URL verzendt, dus de hoeveelheid data die door GET kan worden ingediend is direct gerelateerd aan de lengte van de URL. Er is namelijk geen bovengrens voor URL's, en de HTTP-protocolspecificatie beperkt de lengte van URL's niet. Deze limiet is een beperking die wordt opgelegd door een specifieke browser en server. IE's limiet op URL-lengte is 2083 bytes (2K+35). Voor andere browsers zoals Netscape, Firefox, enzovoort, is er geen theoretische lengtelimiet, en hangt de limiet af van de ondersteuning van het besturingssysteem.
Let op dat dit de volledige URL-lengte beperkt, niet alleen de lengte van je parameterwaarde. [Zie Ref. 5]
(2). Theoretisch heeft POST geen groottelimiet, en de HTTP-protocolspecificatie heeft geen groottelimiet, en het is onjuist te zeggen dat "er een groottelimiet is van 80K/100K voor POST-data", en dat er geen limiet is aan POST-data, en dat het de verwerkingskracht van de handler van de server is die een beperkende rol speelt.
Voor ASP-programma's heeft het Request-object een limiet van 100K datalengte bij het verwerken van elk formulierveld. Maar met Request.BinaryRead is er geen dergelijke beperking.
Hierop heeft Microsoft voor IIS 6.0 de beperkingen om veiligheidsredenen verhoogd. We moeten ook letten op:
1). IIS 6.0 is standaard maximaal 200 KB ASP POST-data, en de limiet is 100 KB per formulierveld.
2). De standaardgrootte van IIS 6.0 uploadbestanden is 4MB.
3). IIS 6.0 heeft standaard een maximale requestheader van 16KB.
Deze beperkingen waren niet beschikbaar vóór IIS 6.0. [Zie Ref. 5]
Dus de bovenstaande 80K en 100K zijn misschien gewoon de standaardwaarden (let op: ik heb de parameters van IIS4 en IIS5 nog niet bevestigd), maar je kunt ze zeker zelf instellen. Aangezien de standaardwaarden voor deze parameters verschillen in elke versie van IIS, raadpleeg u het relevante IIS-configuratiedocument voor details.
3. In ASP gebruikt de server Request.QueryString om de GET-verzoekparameter te verkrijgen en Request.Form om de POST-verzoekparameter te verkrijgen. Gebruik in JSP request.getParameter(\"XXXX\") om het te verkrijgen, hoewel er ook een request.getQueryString()-methode in jsp is, maar die is omslachtiger, bijvoorbeeld: stuur een test.jsp?name=hyddd&password=hyddd, en gebruik request.getQueryString() om :name= te krijgen hyddd&password=hyddd。 In PHP kun je $_GET en $_POST gebruiken om data van respectievelijk GET en POST te halen, terwijl $_REQUEST data kunt halen van zowel GET- als POST-verzoeken. Het is het vermelden waard dat er verborgen gevaren zijn bij het gebruik van request in JSP en $_REQUEST in PHP, wat de volgende keer in een artikel zal worden samengevat.
4.POST is veiliger dan GET. Opmerking: De hier genoemde beveiliging is niet hetzelfde concept als de "beveiliging" die hierboven in de GET wordt genoemd. Als je bijvoorbeeld gegevens via GET indient, verschijnen je gebruikersnaam en wachtwoord in platte tekst op de URL, omdat (1) de inlogpagina mogelijk door de browser wordt gecachet, (2) anderen de browsergeschiedenis bekijken, zodat anderen je account en wachtwoord kunnen krijgen Valsingsaanval.
Samengevat: Get is een verzoek om data van de server op te vragen, terwijl Post een verzoek is om data aan de server te sturen; in FORM staat de methode standaard op "GET", in wezen zijn GET en POST gewoon verschillende verzendmechanismen, er wordt er niet één genomen en verstuurd!
|
Geplaatst op 06-12-2014 10:54:55
|
|
|
Geplaatst op 07-12-2014 17:24:18
