POST (HTTP) - POST (HTTP)

Questo articolo riguarda il metodo HTTP. Non deve essere confuso con l'autotest all'accensione .
HTTP
Metodi di richiesta
Campi di intestazione
Codici di stato di risposta
Metodi di controllo dell'accesso di sicurezza
Vulnerabilità di sicurezza

In informatica , POST è un metodo di richiesta supportato da HTTP utilizzato dal World Wide Web . In base alla progettazione, il metodo di richiesta POST richiede che un server Web accetti i dati racchiusi nel corpo del messaggio di richiesta, molto probabilmente per memorizzarlo. Viene spesso utilizzato quando si carica un file o quando si invia un modulo web compilato .

Al contrario, il metodo di richiesta HTTP GET recupera le informazioni dal server. Come parte di una richiesta GET, alcuni dati possono essere passati all'interno della stringa di query dell'URL , specificando (ad esempio) termini di ricerca, intervalli di date o altre informazioni che definiscono la query.

Come parte di una richiesta POST, una quantità arbitraria di dati di qualsiasi tipo può essere inviata al server nel corpo del messaggio di richiesta. Un campo di intestazione nella richiesta POST di solito indica il tipo di supporto Internet del corpo del messaggio.

Dati di pubblicazione

Il World Wide Web e HTTP si basano su una serie di metodi di richiesta o "verbi", inclusi POST e GET, nonché PUT, DELETE e molti altri. I browser Web normalmente utilizzano solo GET e POST, ma le app online RESTful utilizzano molti degli altri. Il posto di POST nell'intervallo dei metodi HTTP è quello di inviare una rappresentazione di una nuova entità di dati al server in modo che venga archiviata come una nuova subordinata della risorsa identificata dall'URI . Ad esempio, per l'URI , ci si potrebbe aspettare che le richieste POST rappresentino nuovi clienti, ognuno dei quali include il proprio nome, indirizzo, dettagli di contatto e così via. I primi progettisti di siti web si sono allontanati da questo concetto originale in due modi importanti. In primo luogo, non vi è alcun motivo tecnico per un URI per descrivere testualmente la risorsa Web subordinata alla quale verranno archiviati i dati POST. Infatti, a meno che non venga fatto uno sforzo, l'ultima parte di un URI descriverà più probabilmente la pagina di elaborazione dell'applicazione web e la sua tecnologia, come . In secondo luogo, data la limitazione naturale della maggior parte dei browser Web a utilizzare solo GET o POST, i progettisti hanno sentito la necessità di riutilizzare il POST per eseguire molte altre attività di invio e gestione dei dati, inclusa l'alterazione dei record esistenti e la loro eliminazione. http://example.com/customershttp://example.com/applicationform.php

Gli sforzi di alcuni scrittori influenti per rimediare al primo punto sono iniziati già nel 1998. I framework di applicazioni Web come Ruby on Rails e altri rendono più facile per i progettisti fornire ai propri utenti URL semantici . Per quanto riguarda il secondo punto, è possibile utilizzare script lato client , oppure scrivere app standalone, per fare uso degli altri metodi HTTP dove sono rilevanti, ma al di fuori di questo la maggior parte dei moduli web che inviano o alterano i dati del server continuano utilizzare POST per lo scopo.

Questo non vuol dire che ogni modulo web dovrebbe specificare method="post"nel suo tag di apertura . Molti moduli sono utilizzati per specificare con maggiore precisione il recupero delle informazioni dal server, senza alcuna intenzione di alterare il database principale. I moduli di ricerca, ad esempio, sono ideali per aver method="get"specificato.

Ci sono momenti in cui HTTP GET è meno adatto anche per il recupero dei dati. Un esempio di ciò è quando è necessario specificare una grande quantità di dati nell'URL. I browser e i server Web possono avere limiti alla lunghezza dell'URL che gestiranno senza troncamenti o errori. La codifica percentuale dei caratteri riservati negli URL e nelle stringhe di query può aumentare significativamente la loro lunghezza e, mentre Apache HTTP Server può gestire fino a 4.000 caratteri in un URL, Microsoft Internet Explorer è limitato a 2.048 caratteri in qualsiasi URL. Allo stesso modo, HTTP GET non dovrebbe essere utilizzato quando le informazioni sensibili, come nomi utente e password, devono essere inviate insieme ad altri dati per il completamento della richiesta. Anche se viene utilizzato HTTPS , impedendo l'intercettazione dei dati in transito, la cronologia del browser e i registri del server Web conterranno probabilmente l'URL completo in testo normale, che potrebbe essere esposto se uno dei due sistemi viene violato. In questi casi, dovrebbe essere utilizzato HTTP POST.

Utilizzare per l'invio di moduli web

Quando un browser Web invia una richiesta POST da un elemento del modulo Web , il tipo di supporto Internet predefinito è " application/x-www-form-urlencoded ". Questo è un formato per codificare coppie chiave-valore con chiavi eventualmente duplicate. Ogni coppia chiave-valore è separata da un carattere '&' e ogni chiave è separata dal suo valore da un carattere '='. Sia le chiavi che i valori vengono sottoposti a escape sostituendo gli spazi con il carattere '+' e quindi utilizzando la codifica percentuale su tutti gli altri caratteri non alfanumerici .

Ad esempio, le coppie chiave-valore 

Name: Gareth Wylie
Age: 24
Formula: a+b == 21

sono codificati come 

Name=Gareth+Wylie&Age=24&Formula=a%2Bb+%3D%3D+21

A partire da HTML 4.0, i moduli possono anche inviare dati in multipart/form-data come definito in RFC 2388 (vedere anche RFC 1867 per una versione sperimentale precedente definita come estensione di HTML 2.0 e menzionata in HTML 3.2).

Il caso speciale di un POST alla stessa pagina a cui appartiene il modulo è noto come postback .

Influenzare lo stato del server

Per RFC 7231, il metodo POST non è idempotente , il che significa che più richieste identiche potrebbero non avere lo stesso effetto della trasmissione della richiesta una sola volta. Il POST è quindi adatto a richieste che cambiano stato ogni volta che vengono eseguite, ad esempio inviando un commento a un post di un blog o votando in un sondaggio online. GET è definito come nullipotent , senza effetti collaterali e le operazioni idempotenti non hanno "nessun effetto collaterale su richieste secondarie o future". Per questo motivo, i web crawler come gli indicizzatori dei motori di ricerca utilizzano normalmente esclusivamente i metodi GET e HEAD, per impedire alle loro richieste automatizzate di eseguire tali azioni.

Tuttavia, ci sono ragioni per cui POST viene utilizzato anche per richieste idempotenti, in particolare se la richiesta è molto lunga. A causa delle restrizioni sugli URL, la stringa di query generata dal metodo GET potrebbe diventare molto lunga, soprattutto a causa della codifica percentuale .

Riferimenti

link esterno