Qual è la differenza tra una risposta 302 FOUND e una 307 TEMPORARY REDIRECT HTTP?Qual è la differenza tra un reindirizzamento 302 e 307?
The W3 spec sembra indicare che sono entrambi utilizzati per reindirizzamenti temporanei e che nessuno dei due può essere memorizzato nella cache a meno che la risposta non lo consenta specificamente.
Le preoccupazioni differenza reindirizzamento POST, PUT e DELETE richieste e quali sono le aspettative del server sono per il comportamento user agent (RFC 2616):
Nota: RFC 1945 ed RFC 2068 specificare che il cliente è non è consentito a modificare il metodo sulla richiesta reindirizzata . Tuttavia, la maggior parte delle implementazioni di agenti utente esistenti trattano 302 come se si trattasse di una risposta 303, eseguendo un valore GET indipendentemente dal metodo della richiesta originale . I codici di stato 303 e 307 sono stati aggiunti per i server che desiderano per rendere inequivocabile il tipo di reazione di reazione del client .
Inoltre, leggere l'articolo Wikipedia sul 30x redirection codes.
307 avvenne perché gli interpreti hanno adottato come de facto comportamento di prendere richieste POST che ricevono una risposta 302 e inviare una richiesta GET per l'intestazione di risposta Posizione.
Questa è la corretto comportamento — solo un 303 dovrebbe causare un POST si trasformi in un GET. Gli agenti utente devono (ma non) attenersi al metodo POST quando richiedono il nuovo URL se la richiesta POST originale ha restituito un 302.
307 è stato introdotto per consentire ai server di rendere chiaro al programma utente che un cambio di metodo non deve essere eseguito dal client quando si segue l'intestazione di risposta Location.
Alcuni esempi di programmi utente che rispondono in modo errato? Di solito è una percentuale molto piccola di visitatori? – LamonteCristo
@ makerofthings7 Tutti i brower gestiscono erroneamente '302'. Chrome 30, IE10. Divenne l'implementazione * de facto * errata; che non può essere modificato perché così tanti siti Web generano erroneamente il 302. Infatti, ASP.net MVC emette erroneamente 302, * a seconda * del fatto che i browser lo gestiscano in modo errato. –
@IanBoyd Solo i framework delle ragioni fanno ciò perché '303' è stato introdotto con' 307' nelle specifiche HTTP 1.1 e quindi consente la retrocompatibilità con gli user agent HTTP 1.0. Certo, la vera domanda è se dovessimo ancora gestire gli agenti utente HTTP 1.0 a tutti ora? – ewanm89
Un buon esempio di 307 Internal Redirect in azione è quando Google Chrome rileva una chiamata HTTP a un dominio che conosce come severo Transport Security.
Il browser reindirizza senza problemi, utilizzando lo stesso metodo della chiamata originale.
Sai quando Google ha implementato questa funzione? – Tijme
Scusa, non lo so. –
Sì, questo è dove sto vedendo accadere - il nostro server non lo sta inviando - in chrome devtools sembra che sia ma è semplicemente chrome che esegue il reindirizzamento perché abbiamo un'intestazione di Strict Transport Security –
Inoltre, per gli amministratori di server, può essere importante notare che i browser possono presentare una richiesta per l'utente se si utilizzano 307 reindirizzamento.
Ad esempio *, Firefox e Opera richiederebbero all'utente il permesso di reindirizzare, mentre Chrome, IE e Safari eseguiranno il reindirizzamento in modo trasparente.
* per Bulletproof SSL and TLS (pagina 192).
Questo è vero solo per le richieste non sicure, come ad esempio POST. –
EXPECTED per 302: reindirizzamento utilizza lo stesso metodo di richiesta POST su NEW_URL
CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT POST NEW_URL
EFFETTIVA per 302, 303: reindirizzare modifiche richiedono metodo da POST a GET su NEW_URL
CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET)
CLIENT POST OLD_URL -> SERVER 303 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET)
EFFETTIVA per 307 : reindirizzamento utilizza lo stesso metodo di richiesta POST su NEW_URL
CLIENT POST OLD_URL -> SERVER 307 NEW_URL -> CLIENT POST NEW_URL
In alcuni casi d'uso, 307 reindirizzamenti potrebbero essere abusati da un utente malintenzionato per apprendere le credenziali della vittima.
Ulteriori informazioni sono disponibili in sezione 3.1 di A Comprehensive Formal Security Analysis of OAuth 2.0.
Gli autori del documento di cui sopra suggeriscono la seguente:
Fix. Contrariamente all'attuale formulazione nello standard OAuth, il metodo esatto del reindirizzamento non è un dettaglio di implementazione ma essenziale per la sicurezza di OAuth. Nello standard HTTP (RFC 7231), solo il reindirizzamento 303 è definito in modo univoco per eliminare il corpo di una richiesta POST HTTP. Tutti gli altri codici di stato di reindirizzamento HTTP, incluso il 302 più comunemente usato, lasciano al browser l'opzione per conservare la richiesta POST ei dati del modulo. In pratica, i browser di solito eseguono la riscrittura su una richiesta GET, eliminando quindi i dati del modulo, ad eccezione dei reindirizzamenti 307. Pertanto, lo standard OAuth dovrebbe richiedere 303 reindirizzamenti per i passaggi sopra menzionati per risolvere questo problema.
Quindi, da un punto di vista parser/agente/browser, possiamo semplicemente considerare 302 e 307 identici, giusto? (È possibile utilizzare ** lo stesso codice ** esatto per gestire entrambi i casi senza ulteriore distinzione?) – Pacerier
No: è possibile trattare 302 e 303 come identici, ma 307 è diverso. –
@kkhugs, In nessun modo, per ottenere get-302 è necessario un browser 1.0 allo stesso modo di get-307 è fatto in 1.1 browser. È richiesto un browser 1.0 per fare post-302 nello stesso modo in cui ottiene get-302, tranne che per prima cosa deve richiedere la conferma da parte dell'utente e il metodo deve essere post. – Pacerier