HTTP INVIARE le richieste forniscono dati aggiuntivi dal client (browser) al server nel corpo del messaggio. In contrasto, OTTENERE le richieste includono tutti i dati richiesti nell'URL. I moduli in HTML possono utilizzare entrambi i metodi specificando method = "POST" o method = "GET" (predefinito) in elemento. Il metodo specificato determina in che modo i dati del modulo vengono inviati al server. Quando il metodo è GET, tutti i dati del modulo sono codificati nell'URL, aggiunto al azione URL come parametri della stringa di query. Con POST, i dati del modulo vengono visualizzati all'interno del corpo del messaggio della richiesta HTTP.
OTTENERE | INVIARE | |
---|---|---|
Storia | I parametri rimangono nella cronologia del browser perché fanno parte dell'URL | I parametri non vengono salvati nella cronologia del browser. |
segnalibro | Può essere aggiunto ai segnalibri. | Non può essere aggiunto ai segnalibri. |
Pulsante INDIETRO / ripresenta comportamento | Le richieste GET vengono rieseguite ma potrebbero non essere nuovamente inviate al server se l'HTML è archiviato nella cache del browser. | Il browser di solito avvisa l'utente che i dati dovranno essere nuovamente inviati. |
Tipo di codifica (attributo enctype) | application / x-www-form-urlencoded | multipart / form-data o application / x-www-form-urlencoded Usa la codifica multipart per i dati binari. |
parametri | può inviare ma i dati dei parametri sono limitati a ciò che possiamo inserire nella riga di richiesta (URL). Più sicuro usare meno di 2K di parametri, alcuni server gestiscono fino a 64K | Può inviare parametri, incluso il caricamento di file, al server. |
Violato | Più facile da hackerare per gli script kiddies | Più difficile da hackerare |
Restrizioni sul tipo di dati del modulo | Sì, sono ammessi solo caratteri ASCII. | Senza restrizioni. Sono consentiti anche dati binari. |
Sicurezza | GET è meno sicuro rispetto al POST perché i dati inviati fanno parte dell'URL. Quindi viene salvato nella cronologia del browser e nei log del server in testo semplice. | Il POST è un po 'più sicuro di GET perché i parametri non sono memorizzati nella cronologia del browser o nei registri del server web. |
Restrizioni sulla lunghezza dei dati del modulo | Sì, poiché i dati del modulo si trovano nell'URL e la lunghezza dell'URL è limitata. Un limite di lunghezza URL sicuro è spesso di 2048 caratteri ma varia in base al browser e al server web. | Senza restrizioni |
usabilità | Il metodo GET non deve essere utilizzato quando si inviano password o altre informazioni sensibili. | Metodo POST utilizzato quando si inviano password o altre informazioni sensibili. |
Visibilità | Il metodo GET è visibile a tutti (verrà visualizzato nella barra degli indirizzi del browser) e ha limiti sulla quantità di informazioni da inviare. | Le variabili del metodo POST non sono visualizzate nell'URL. |
Copia cache | Può essere memorizzato nella cache | Non memorizzato nella cache |
La differenza fondamentale tra Method = "get" e Method = "post" è che corrispondono a richieste HTTP diverse, come definito nelle specifiche HTTP. Il processo di invio per entrambi i metodi inizia nello stesso modo: un set di dati del modulo viene costruito dal browser e quindi codificato in un modo specificato dal enctype attributo. Per Method = "post il enctype l'attributo può essere / Form-data multipart o application / x-www-form-urlencoded, mentre per Method = "get", solo application / x-www-form-urlencoded È permesso. Questo set di dati del modulo viene quindi trasmesso al server.
Per l'invio di moduli con METHOD = "GET", il browser costruisce un URL prendendo il valore di azione attributo, aggiungendo a ? ad esso, quindi aggiungendo il set di dati del modulo (codificato utilizzando il tipo di contenuto application / x-www-form-urlencoded). Il browser elabora quindi questo URL come se seguisse un collegamento (o come se l'utente avesse digitato direttamente l'URL). Il browser divide l'URL in parti e riconosce un host, quindi invia a quell'host una richiesta GET con il resto dell'URL come argomento. Il server lo prende da lì. Si noti che questo processo significa che i dati del modulo sono limitati ai codici ASCII. È necessario prestare particolare attenzione per codificare e decodificare altri tipi di caratteri durante il loro passaggio attraverso l'URL in formato ASCII.
L'invio di un modulo con METHOD = "POST" provoca l'invio di una richiesta POST, utilizzando il valore di azione attributo e un messaggio creato in base al tipo di contenuto specificato dal enctype attributo.
Poiché i dati del modulo vengono inviati come parte dell'URL quando OTTENERE viene usato --
In linea di principio, l'elaborazione dei dati di un modulo inviato dipende dal fatto che sia stata inviata con Method = "get" o Method = "post". Poiché i dati sono codificati in modi diversi, sono necessari diversi meccanismi di decodifica. Pertanto, in generale, la modifica del METODO può richiedere una modifica dello script che elabora l'invio. Ad esempio, quando si utilizza l'interfaccia CGI, lo script riceve i dati in una variabile di ambiente (QUERYSTRING) quando OTTENERE viene usato. Ma quando INVIARE viene utilizzato, i dati del modulo vengono passati nello stream di input standard (stdin) e il numero di byte da leggere è dato dall'intestazione Content-length.
GET è raccomandato quando si inviano moduli "idempotenti" - quelli che non "alterano significativamente lo stato del mondo". In altre parole, moduli che riguardano solo le query del database. Un'altra prospettiva è che diverse query idempotent avranno lo stesso effetto di una singola query. Se sono coinvolti aggiornamenti del database o altre azioni come l'attivazione di e-mail, si consiglia l'uso di POST.
Dal blog degli sviluppatori Dropbox:
un browser non sa esattamente cosa fa un particolare modulo HTML, ma se il modulo viene inviato tramite HTTP GET, il browser sa che è sicuro riprovare automaticamente l'invio se si verifica un errore di rete. Per i moduli che utilizzano HTTP POST, potrebbe non essere sicuro riprovare in modo che il browser chieda prima conferma all'utente.
Una richiesta "GET" è spesso memorizzabile nella cache, mentre una richiesta "POST" può difficilmente essere. Per i sistemi di query questo può avere un notevole impatto sull'efficienza, specialmente se le stringhe della query sono semplici, poiché le cache potrebbero servire le query più frequenti.
In alcuni casi, usando INVIARE è raccomandato anche per le query idempotent:
Aggiornato il 15 maggio 2015: in particolare quando si utilizza HTTPS (HTTP su TLS / SSL), il POST offre una sicurezza maggiore rispetto a GET?
Questa è una domanda interessante. Supponiamo che tu faccia una richiesta GET a una pagina web:
OTTIENI https://www.example.com/login.php?user=mickey&passwd=mini
Supponendo che la tua connessione Internet sia monitorata, quali informazioni su questa richiesta saranno disponibili per il snooper? Se invece viene utilizzato il POST e i dati dell'utente e passwd sono inclusi nelle variabili POST, ciò sarà più sicuro nel caso di connessioni HTTPS?
La risposta è no. Se si effettua una richiesta GET, solo le seguenti informazioni saranno note all'attaccante che monitora il traffico Web:
La parte del percorso dell'URL, ovvero la pagina effettiva richiesta, nonché i parametri della stringa di query, sono protetti (crittografati) mentre sono "over the wire", cioè in transito sulla loro strada verso il server di destinazione. La situazione è esattamente la stessa per le richieste POST.
Ovviamente, i server Web tendono a registrare l'intero URL in formato testo nei loro log di accesso; pertanto l'invio di informazioni sensibili su GET non è una buona idea. Questo vale indipendentemente dal fatto che venga utilizzato HTTP o HTTPS.