OTTIENI vs. POST

Le richieste HTTP POST forniscono dati aggiuntivi dal client (browser) al server nel corpo del messaggio. Al contrario, le richieste GET includono tutti i dati richiesti nell'URL. I moduli in HTML possono utilizzare entrambi i metodi specificando method = "POST" o method = "GET" (impostazione predefinita) in elemento. Il metodo specificato determina il modo in cui i dati del modulo vengono inviati al server. Quando il metodo è GET, tutti i dati del modulo vengono codificati nell'URL, aggiunto all'URL dell'azione come parametri della stringa di query. Con POST, i dati del modulo vengono visualizzati nel corpo del messaggio della richiesta HTTP.

Tabella di confronto

OTTIENI contro la tabella di confronto POST
OTTENERE INVIARE
StoriaI parametri rimangono nella cronologia del browser perché fanno parte dell'URLI parametri non vengono salvati nella cronologia del browser.
AggiuntoPuò essere aggiunto ai segnalibri.Non può essere aggiunto ai segnalibri.
Pulsante INDIETRO / reinvio comportamentoLe richieste GET vengono rieseguite ma potrebbero non essere reinviate al server se l'HTML è archiviato nella cache del browser.Il browser di solito avvisa l'utente che i dati dovranno essere reinviati.
Tipo di codifica (attributo enctype)application / x-www-form-urlencodedmultipart / form-data o application / x-www-form-urlencoded Utilizza la codifica multipart per i dati binari.
parametripuò inviare ma i dati dei parametri sono limitati a ciò che possiamo inserire nella riga di richiesta (URL). Più sicuro di utilizzare meno di 2 KB di parametri, alcuni server gestiscono fino a 64 KBPuò inviare parametri, incluso il caricamento di file, al server.
ViolatoPiù facile da hackerare per gli script kiddiePiù difficile da hackerare
Restrizioni sul tipo di dati del moduloSì, sono ammessi solo caratteri ASCII.Senza restrizioni. Sono ammessi anche dati binari.
SicurezzaOTTENERE è 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 normale.POST è un po 'più sicuro di GET perché i parametri non sono memorizzati nella cronologia del browser o nei registri del web server.
Restrizioni sulla lunghezza dei dati del moduloSì, poiché i dati del modulo si trovano nell'URL e la lunghezza dell'URL è limitata. Un limite di lunghezza dell'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 riservate.Metodo POST utilizzato durante l'invio di password o altre informazioni riservate.
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 vengono visualizzate nell'URL.
Copia cachePuò essere memorizzato nella cacheNon memorizzato nella cache

Differenze nell'invio del modulo

La differenza fondamentale tra METHOD = "GET" e METHOD = "POST" è che corrispondono a diverse richieste HTTP, come definito nelle specifiche HTTP. Il processo di invio per entrambi i metodi inizia allo stesso modo: un set di dati del modulo viene creato dal browser e quindi codificato in un modo specificato dall'attributo enctype . Per METHOD = "POST l'attributo enctype può essere multipart / form-data o application / x-www-form-urlencoded, mentre per METHOD =" GET ", è consentita solo application / x-www-form-urlencoded . set viene quindi trasmesso al server.

Per l'invio del modulo con METHOD = "GET", il browser crea un URL assumendo il valore dell'attributo action, aggiungendo un ? ad esso, quindi aggiungendo il set di dati del modulo (codificato utilizzando il tipo di contenuto application / x-www-form-urlencoded). Il browser quindi elabora questo URL come seguendo un collegamento (o come se l'utente avesse digitato l'URL direttamente). Il browser divide l'URL in parti e riconosce un host, quindi invia a tale 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. Prestare particolare attenzione a codificare e decodificare altri tipi di caratteri quando li si passa attraverso l'URL in formato ASCII.

L'invio di un modulo con METHOD = "POST" comporta l'invio di una richiesta POST, utilizzando il valore dell'attributo action e un messaggio creato in base al tipo di contenuto specificato dall'attributo enctype .

Pro e contro

Poiché i dati del modulo vengono inviati come parte dell'URL quando viene utilizzato GET -

  • I dati del modulo sono limitati ai codici ASCII. Prestare particolare attenzione a codificare e decodificare altri tipi di caratteri quando li si passa attraverso l'URL in formato ASCII. D'altra parte, i dati binari, le immagini e altri file possono essere inviati tramite METHOD = "POST"
  • Tutti i dati del modulo compilati sono visibili nell'URL. Inoltre, è anche memorizzato nella cronologia / registri di navigazione web dell'utente per il browser. Questi problemi rendono GET meno sicuro.
  • Tuttavia, uno dei vantaggi dei dati del modulo inviati come parte dell'URL è che è possibile contrassegnare gli URL e utilizzarli direttamente e bypassare completamente il processo di compilazione del modulo.
  • Esiste una limitazione sulla quantità di dati di modulo che è possibile inviare perché la lunghezza degli URL è limitata.
  • Gli script kiddie possono esporre più facilmente le vulnerabilità nel sistema per hackerarlo. Ad esempio, Citibank è stato violato modificando i numeri di account nella stringa URL. [1] Naturalmente, hacker esperti o sviluppatori web possono esporre tali vulnerabilità anche se viene utilizzato POST; è solo un po 'più difficile. In generale, il server deve essere sospettoso di tutti i dati inviati dal client e proteggersi da riferimenti a oggetti diretti non sicuri.

Differenze nell'elaborazione lato server

In linea di principio, l'elaborazione dei dati di un modulo inviato dipende dal fatto che vengano inviati 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 della sceneggiatura che elabora l'invio. Ad esempio, quando si utilizza l'interfaccia CGI, lo script riceve i dati in una variabile di ambiente (QUERYSTRING) quando viene utilizzato GET . Ma quando si utilizza POST, i dati del modulo vengono passati nel flusso di input standard ( stdin ) e il numero di byte da leggere viene fornito dall'intestazione Content-length.

Utilizzo raccomandato

Si raccomanda di ottenere l'invio di moduli "idempotenti", quelli che non "alterano in modo significativo lo stato del mondo". In altre parole, i moduli che coinvolgono solo query di database. Un'altra prospettiva è che diverse query idempotenti 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'utilizzo di POST.

Dal blog degli sviluppatori di 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 è possibile riprovare automaticamente l'invio in caso di errore di rete. Per i moduli che utilizzano HTTP POST, potrebbe non essere sicuro riprovare, quindi il browser richiede prima all'utente la conferma.

Una richiesta "GET" è spesso memorizzabile nella cache, mentre una richiesta "POST" difficilmente può esserlo. Per i sistemi di query ciò può avere un notevole impatto sull'efficienza, specialmente se le stringhe di query sono semplici, poiché le cache potrebbero servire le query più frequenti.

In alcuni casi, l'utilizzo di POST è consigliato anche per query idempotenti:

  • Se i dati del modulo conterrebbero caratteri non ASCII (come i caratteri accentati), METHOD = "GET" non è applicabile in linea di principio, sebbene possa funzionare in pratica (principalmente per i caratteri ISO Latino 1).
  • Se il set di dati del modulo è di grandi dimensioni, ad esempio centinaia di caratteri, METHOD = "GET" può causare problemi pratici con implementazioni che non possono gestire URL così lunghi.
  • Potresti voler evitare METHOD = "GET" per rendere meno visibile agli utenti il ​​funzionamento del modulo, in particolare per rendere i campi "nascosti" (INPUT TYPE = "HIDDEN") più nascosti non comparendo nell'URL. Ma anche se usi campi nascosti con METHOD = "POST", appariranno comunque nel codice sorgente HTML.

Che dire di HTTPS?

Aggiornato il 15 maggio 2015: in particolare quando si utilizza HTTPS (HTTP su TLS / SSL), POST offre più sicurezza di GET?

Questa è una domanda interessante Supponi di effettuare una richiesta GET a una pagina Web:

 OTTIENI //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 lo snooper? Se si utilizza invece POST e i dati utente e passwd sono inclusi nelle variabili POST, sarà più sicuro nel caso delle connessioni HTTPS?

La risposta è no. Se invii tale richiesta GET, solo le seguenti informazioni saranno note all'attaccante che controlla il tuo traffico web:

  1. Il fatto che hai effettuato una connessione HTTPS
  2. Il nome host - www.esempio.com
  3. La lunghezza totale della richiesta
  4. La lunghezza della risposta

La parte del percorso dell'URL, ovvero la pagina effettiva richiesta, così come i parametri della stringa di query, sono protetti (crittografati) mentre sono "over the wire", cioè in transito verso il server di destinazione. La situazione è esattamente la stessa per le richieste POST.

Naturalmente, i server Web tendono a registrare l'intero URL in testo semplice nei loro registri di accesso; quindi l'invio di informazioni sensibili tramite GET non è una buona idea. Ciò vale indipendentemente dall'uso di HTTP o HTTPS.

Articoli Correlati