HTTP definisce diversi modi di interagire con il server, e ci sono 4 metodi di base, ovvero GET, POST, PUT e DELETE. Il nome completo dell'URL è un descrittore di risorse, possiamo pensarlo così: un indirizzo URL, viene usato per descrivere una risorsa su una rete, e GET, POST, PUT, DELETE in HTTP corrisponde alle quattro operazioni di verificare, modificare, aggiungere ed eliminare questa risorsa. A questo punto, dovresti avere una comprensione generale: GET viene generalmente usato per ottenere/interrogare informazioni sulle risorse, mentre POST viene generalmente usato per aggiornare le informazioni sulle risorse.
1. Secondo la specifica HTTP, GET viene utilizzato per il recupero delle informazioni e dovrebbe essere sicuro e idempotente.
(1). La cosiddetta sicurezza significa che l'operazione viene utilizzata per ottenere informazioni piuttosto che modificarle. In altre parole, le richieste GET generalmente non dovrebbero avere effetti collaterali. Cioè, ottiene solo informazioni sulle risorse, proprio come le query del database, e non modifica, aggiunge dati o influenza lo stato della risorsa.
* Nota: Il significato di sicurezza qui si riferisce solo a informazioni non modificate.
(2). idempotente significa che più richieste sullo stesso URL dovrebbero restituire lo stesso risultato.
Tuttavia, nella pratica, le due normative sopra menzionate non sono così rigide. Esempi di citazioni di articoli altrui: ad esempio, la prima pagina di un sito di notizie è costantemente aggiornata. Sebbene la seconda richiesta restituisca un lotto diverso di notizie, l'operazione è comunque considerata sicura e idempotente perché restituisce sempre le notizie attuali. Fondamentalmente, se l'obiettivo è che quando un utente apre un link, possa essere sicuro che la risorsa non sia stata modificata dal suo punto di vista.
2. Secondo la specifica HTTP, POST rappresenta una richiesta che può modificare una risorsa sul server. Continuando a citare l'esempio sopra: Notizie ancora Prendiamo il sito web come esempio, i lettori dovrebbero pubblicare i propri commenti sulle notizie, perché le risorse del sito cambiano dopo che il commento è stato inviato o le risorse sono state modificate.
Quanto sopra discute approssimativamente alcuni dei principi di GET e POST nella specifica HTTP. Tuttavia, molte persone non seguono la specifica HTTP quando lo fanno effettivamente, il che può portare a molte ragioni per questo problema, come:
1. Molte persone usano GET per aggiornare le risorse perché devono andare su FORM per usare POST, il che può essere un po' complicato.
2. L'operazione di aggiunta, cancellazione, modifica e verifica delle risorse può effettivamente essere completata tramite GET/POST, senza la necessità di usare PUT e DELETE.
3. Un altro è che i primi progettisti di framework Web MVC non trattavano e progettavano consapevolmente gli URL come risorse astratte, quindi un problema serio è che il framework tradizionale Web MVC supporta fondamentalmente solo due metodi HTTP, GET e POST, ma non supporta i metodi PUT e DELETE.
* Una breve spiegazione di MVC: MVC esisteva originariamente nel programma Desktop, M si riferisce al modello dati, V all'interfaccia utente e C al controller. Lo scopo dell'uso del MVC è separare il codice di implementazione di M e V, in modo che lo stesso programma possa utilizzare rappresentazioni diverse.
I 3 punti sopra descritti tipicamente descrivono il vecchio stile (senza una rigorosa aderenza alla specifica HTTP); con lo sviluppo dell'architettura, ora esiste REST (Representational State Transfer), un nuovo stile che supporta la specifica HTTP.
Dopo aver parlato del problema principale, vediamo la differenza tra GET e POST rispetto al fenomeno superficiale:
1. I dati della richiesta GET saranno allegati all'URL (cioè, i dati sono inseriti nell'intestazione del protocollo HTTP), e il ? Dividi l'URL e trasmetti i dati, e i parametri sono collegati da &, ad esempio: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Se i dati sono lettere/numeri inglesi, inviali così com'è; se è uno spazio, convertili in +; se sono cinesi/altri caratteri, poi cifra direttamente la stringa con BASE64 per ottenere un campione come: %E4%BD%A0%E5%A5%BD, dove XX in %XX è l'ASCII rappresentato dal simbolo in esadecimale.
POST inserisce i dati inviati nel corpo del pacchetto HTTP.
2. "Il massimo dei dati inviati dal metodo GET può essere solo di 1024 byte, teoricamente non c'è limite al POST, e può essere trasferita una grande quantità di dati, fino a 80KB in IIS4 e 100KB in IIS5"??!
La frase sopra è stata reindirizzata da altri articoli, infatti è sbagliato e inaccurato dire questo:
(1). Innanzitutto, "i dati inviati dal metodo GET possono essere al massimo 1024 byte", perché GET invia i dati tramite URL, quindi la quantità di dati che può essere inviata da GET è direttamente correlata alla lunghezza dell'URL. In realtà, non esiste un limite massimo di parametri per gli URL, e la specifica del protocollo HTTP non limita la lunghezza degli URL. Questo limite è imposto da un browser e server specifici. Il limite di lunghezza URL di IE è di 2083 byte (2K+35). Per altri browser come Netscape, Firefox, ecc., non esiste un limite teorico di lunghezza, e il suo limite dipende dal supporto del sistema operativo.
Nota che questo limita l'intera lunghezza dell'URL, non solo la lunghezza dei dati del valore del parametro. [Vedi Rif. 5]
(2). Teoricamente, POST non ha un limite di dimensione, e la specifica del protocollo HTTP non ha un limite di dimensione, ed è impreciso affermare che "esiste un limite di dimensione di 80K/100K per i dati POST", non c'è limite ai dati POST, ed è la potenza di calcolo del gestore del server a svolgere un ruolo limitante.
Per i programmi ASP, l'oggetto Request ha un limite di lunghezza dati di 100K quando elabora ogni campo di modulo. Ma con Request.BinaryRead non esiste tale limitazione.
Da questo prolungato, per IIS 6.0, Microsoft ha aumentato le restrizioni per motivi di sicurezza. Dobbiamo anche prestare attenzione a:
1). IIS 6.0 predefinito ha un massimo di 200 KB di dati ASP POST, e il limite è di 100 KB per campo modulo.
2). La dimensione predefinita dei file di upload di IIS 6.0 è di 4MB.
3). IIS 6.0 imposta di default un'intestazione massima di richiesta di 16KB.
Queste limitazioni non erano disponibili prima di IIS 6.0. [Vedi Rif. 5]
Quindi gli 80K e 100K sopra potrebbero essere solo i valori predefiniti (nota: non ho ancora confermato i parametri di IIS4 e IIS5), ma puoi sicuramente impostarli da solo. Poiché i valori predefiniti di questi parametri sono diversi in ciascuna versione di IIS, si prega di consultare il documento di configurazione IIS pertinente per i dettagli.
3. In ASP, il server utilizza Request.QueryString per ottenere il parametro richiesta GET e Request.Form per ottenere il parametro richiesta POST. In JSP, usa request.getParameter(\"XXXX\") per ottenerlo, anche se in jsp esiste anche un metodo request.getQueryString(), ma è più difficile da usare, ad esempio: invia un test.jsp?name=hyddd&password=hyddd, e usa request.getQueryString() per ottenere :name= hyddd&password=hyddd。 In PHP, puoi usare $_GET e $_POST per ottenere dati rispettivamente da GET e POST, mentre $_REQUEST può ottenere dati sia da richieste GET che POST. Vale la pena notare che ci sono pericoli nascosti nell'usare la richiesta in JSP e _REQUEST dollari in PHP, che saranno riassunti in un articolo la prossima volta.
4.POST è più sicuro di GET. Nota: La sicurezza menzionata qui non è lo stesso concetto della "sicurezza" menzionata nel GET sopra. Ad esempio, se invii dati tramite GET, il tuo nome utente e la password appariranno in testo chiaro sull'URL, perché (1) la pagina di accesso potrebbe essere memorizzata nella cache dal browser, (2) altri vedranno la cronologia del browser, così gli altri potranno ottenere il tuo account e la tua password Attacco di falsificazione.
In sintesi, Get è una richiesta per richiedere dati al server, mentre Post è una richiesta per inviare dati al server, in FORM il metodo predefinito è "GET", in sostanza, GET e POST sono solo meccanismi di invio diversi, non uno prende e invia uno!
|
Pubblicato su 06/12/2014 10:54:55
|
|
|
Pubblicato su 07/12/2014 17:24:18
