Perché HTTP non ha il reindirizzamento POST?

I reindirizzamenti HTTP vengono effettuati tramite i codici HTTP 301 e 302 (forse anche altri codici) e un campo di intestazione noto come "Posizione" che ha l'indirizzo del nuovo posto dove andare. Tuttavia, i browser inviano sempre una richiesta "GET" a tale URL.

Tuttavia, molte volte è necessario reindirizzare l'utente a un altro dominio tramite POST (ad esempio pagamenti bancari). Questo è uno scenario comune e davvero un requisito. Qualcuno sa perché un requisito così comune è stato trascurato nelle specifiche HTTP? Per risolvere il problema, inviare un modulo (con parametri in campi nascosti) con azione impostata sulla posizione di destinazione (il valore del campo di intestazione Posizione ) e utilizzare setTimeoutper inviare il modulo alla posizione di destinazione.

In HTTP 1.1, esiste effettivamente un codice di stato ( 307 ) che indica che la richiesta deve essere ripetuta utilizzando lo stesso metodo e post dati .

Come altri hanno già detto, esiste un potenziale uso improprio qui che può essere il motivo per cui molti framework si attengono a 301 e 302 nelle loro astrazioni. Tuttavia, con una comprensione adeguata e un uso responsabile, dovresti essere in grado di realizzare ciò che stai cercando.

Si noti che in base alle specifiche di W3.org , quando non lo METHODè HEADo GET, gli user agent dovrebbero richiedere all'utente prima di rieseguire la richiesta nella nuova posizione. Dovresti anche fornire una nota e un meccanismo di fallback per l'utente nel caso in cui i vecchi user agent non siano sicuri di cosa fare con un 307.

Utilizzando questo modulo:

<form action="Test307.aspx" method="post">
    <input type="hidden" name="test" value="the test" />
    <input type="submit" value="test" />    
</form>

E avere Test307.aspx restituisce semplicemente 307 con la posizione: http://google.com , Chrome 13 e Fiddler confermano che "test = il test" è effettivamente pubblicato su Google. Naturalmente l'ulteriore risposta è un 405 poiché Google non consente il POST, ma mostra la meccanica.

Per ulteriori informazioni, consultare Elenco dei codici di stato HTTP e le specifiche di W3.org .

307 Reindirizzamento temporaneo (da HTTP / 1.1) In questa occasione, la richiesta deve essere ripetuta con un altro URI, ma le richieste future possono comunque utilizzare l'URI originale. 2 Contrariamente a 303, il metodo di richiesta non deve essere modificato durante la riemissione della richiesta originale. Ad esempio, una richiesta POST deve essere ripetuta utilizzando un'altra richiesta POST.

Ho trovato una buona spiegazione in questa pagina qui .

Le situazioni più semplici sul WWW sono transazioni "idempotenti", cioè quelle che possono essere ripetute senza causare alcun danno. Si tratta in genere di transazioni "GET", sia perché vengono recuperati riferimenti URL semplici (ad esempio href = o src = attributi in HTML), sia perché sono invii di moduli mediante il metodo GET. Il reindirizzamento di una transazione di quel tipo è semplice e non vengono poste domande: il client riceve la risposta di reindirizzamento, inclusa un'intestazione Location: che specifica il nuovo URL, e il client reagisce ad esso emettendo nuovamente la transazione nel nuovo URL. C'è una differenza tra i diversi codici di stato 30x associati a questi reindirizzamenti nella loro cache implicita, ma per il resto sono sostanzialmente simili (301 e 302) in risposta alle richieste GET.

Le transazioni POST sono diverse, poiché sono definite, in linea di principio, non idempotenti (come ordinare una pizza, esprimere un voto o altro) e non devono essere ripetute arbitrariamente.

Le specifiche del protocollo HTTP sono progettate per tenere conto di questa distinzione: il metodo GET è definito intrinsecamente idempotente, mentre il metodo POST è definito, almeno potenzialmente, non idempotente; le specifiche richiedono una serie di precauzioni che gli agenti client (come i browser) devono adottare per proteggere gli utenti da (in) reindirizzamento involontario di una transazione POST che non avevano previsto o inoltrare un POST in un contesto che non avrebbero voluto .

Anche se non sono un fan di limitare tecnicamente gli utenti per impedire loro di causare caos indesiderati o di fare danni indesiderati alle loro applicazioni, posso capire il punto e ha senso.

GET (e alcuni altri metodi) sono definiti come "SICURI" nelle specifiche http ( RFC 2616 ):

9.1.1 Metodi sicuri

I responsabili dell'implementazione devono essere consapevoli del fatto che il software rappresenta l'utente nelle loro interazioni su Internet e dovrebbero fare attenzione a consentire all'utente di essere a conoscenza di eventuali azioni che potrebbero avere che potrebbero avere un significato inaspettato per se stessi o per gli altri.

In particolare, è stata stabilita la convenzione che i metodi GET e HEAD NON DOVREBBERO avere il significato di intraprendere un'azione diversa dal recupero. Questi metodi dovrebbero essere considerati "sicuri". Ciò consente agli interpreti utenti di rappresentare altri metodi, come POST, PUT e DELETE, in modo speciale, in modo che l'utente venga a conoscenza del fatto che viene richiesta un'azione potenzialmente non sicura.

Naturalmente, non è possibile garantire che il server non generi effetti collaterali a seguito dell'esecuzione di una richiesta GET; in effetti, alcune risorse dinamiche ritengono che una caratteristica. La distinzione importante qui è che l'utente non ha richiesto gli effetti collaterali, quindi non può essere ritenuto responsabile per loro.

Ciò significa che una richiesta GET non dovrebbe mai avere conseguenze gravi per l'utente, oltre a vedere qualcosa che potrebbe non voler vedere, ma una richiesta POST potrebbe cambiare una risorsa che è importante per loro o per altre persone.

Sebbene ciò sia cambiato con JavaScript, tradizionalmente c'erano diverse interfacce utente: gli utenti potevano attivare le richieste GET facendo clic sui collegamenti, ma avrebbero dovuto compilare un modulo per attivare una richiesta POST. Penso che i progettisti di HTTP abbiano voluto mantenere la distinzione tra metodi sicuri e metodi non sicuri.

Inoltre, non penso che dovrebbe mai essere necessario reindirizzare a un POST. Qualsiasi azione che deve essere eseguita può presumibilmente essere eseguita chiamando una funzione all'interno del codice lato server, oppure se deve avvenire su un server diverso, anziché inviare un reindirizzamento contenente un URL per il browser a POST al server potrebbe effettuare una richiesta al server stesso, fungendo da proxy per l'utente.