GET vs. POST

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.

Grafico comparativo

GET contro il grafico di confronto POST
OTTENEREINVIARE
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

Contenuto: GET vs POST

  • 1 differenze nella presentazione del modulo
    • 1.1 Pro e contro
  • 2 differenze nell'elaborazione lato server
  • 3 Uso consigliato
  • 4 Che dire di HTTPS?
  • 5 riferimenti

Differenze nella presentazione del modulo

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.

Pro e contro

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

  • 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. D'altra parte, i dati binari, le immagini e altri file possono essere inviati Method = "post"
  • Tutti i dati del modulo compilati sono visibili nell'URL. Inoltre, è anche memorizzato nella cronologia di navigazione web dell'utente / registri per il browser. Questi problemi fanno OTTENERE meno sicuro.
  • Tuttavia, un vantaggio dei dati del modulo inviati come parte dell'URL è che si possono aggiungere ai segnalibri gli URL e utilizzarli direttamente e ignorare completamente il processo di compilazione del modulo.
  • Esiste una limitazione sulla quantità di dati dei moduli che possono essere inviati perché le lunghezze degli URL sono limitate.
  • Script kiddies può più facilmente esporre vulnerabilità nel sistema per hackerarlo. Ad esempio, Citibank è stato violato cambiando i numeri di conto nella stringa dell'URL.[1] Naturalmente, hacker esperti o sviluppatori web possono esporre tali vulnerabilità anche se si utilizza il POST; è solo un po 'più difficile. In generale, il server deve essere sospettoso di qualsiasi dato inviato dal client e proteggere da riferimenti agli oggetti diretti insicuri.

Differenze nell'elaborazione lato server

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.

Uso consigliato

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:

  • Se i dati del modulo contengono caratteri non ASCII (come i caratteri accentati), quindi Method = "get" è inapplicabile in linea di principio, sebbene possa funzionare nella pratica (principalmente per caratteri ISO Latin 1).
  • Se il set di dati del modulo è grande - diciamo, centinaia di personaggi - quindi Method = "get" può causare problemi pratici con implementazioni che non possono gestire URL lunghi.
  • Potresti voler evitare Method = "get" per rendere meno visibile agli utenti il ​​funzionamento del modulo, soprattutto per rendere i campi "nascosti" (INPUT TYPE = "HIDDEN") più nascosti non comparendo nell'URL. Ma anche se usi campi nascosti con Method = "post", essi appariranno ancora nel codice sorgente HTML.

Che dire di HTTPS?

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:

  1. Il fatto che tu abbia fatto 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, 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.

Riferimenti

  • wikipedia: POST (HTTP)
  • Metodi di richiesta HTTP
  • HTTP Post - W3.org
  • Get HTTP - W3.org
  • HTTPS nasconde gli URL a cui si accede? - Stack Exchange