Qual è la differenza tra a 302 FOUNDe a307 TEMPORARY REDIRECT risposta ae HTTP?
Le specifiche W3 sembrano indicare che sono entrambe utilizzate per reindirizzamenti temporanei e nessuna delle due può essere memorizzata nella cache a meno che la risposta non lo consenta espressamente.
Risposte:
Le preoccupazioni differenza reindirizzamento POST, PUTe DELETEle richieste e quali sono le aspettative del server sono per il comportamento user agent ( RFC 2616):
Nota: RFC 1945 e RFC 2068 specificano che al client non è consentito modificare il metodo sulla richiesta reindirizzata. Tuttavia, la maggior parte delle implementazioni degli user agent esistenti considera 302 come se fosse una risposta 303, eseguendo un GET sul valore del campo Posizione indipendentemente dal metodo di richiesta originale. I codici di stato 303 e 307 sono stati aggiunti per i server che desiderano chiarire in modo inequivocabile il tipo di reazione prevista per il client.
Inoltre, leggi l'articolo di Wikipedia sui codici di reindirizzamento 30x .
307 è nato perché gli user agent hanno adottato di fatto un comportamento per accettare le richieste POST che ricevono una risposta 302 e inviare una richiesta GET all'intestazione della risposta della posizione.
Questo è un comportamento errato : solo un 303 dovrebbe far sì che un POST si trasformi in un GET. Gli interpreti dovrebbero (ma non) attenersi al metodo POST quando si richiede il nuovo URL se la richiesta POST originale ha restituito un 302.
307 è stato introdotto per consentire ai server di chiarire all'agente utente che il client non deve apportare una modifica del metodo quando segue l'intestazione della risposta della posizione.
302non vengono gestiti correttamente. Chrome 30, IE10. È diventata di fatto un'implementazione errata; che non può essere modificato perché così tanti siti web emettono erroneamente 302. In realtà ASP.net MVC emette erroneamente 302, a seconda del fatto che i browser lo gestiscono in modo errato.
303stato introdotto anche 307nella specifica HTTP 1.1 e quindi consente la retrocompatibilità con i programmi utente HTTP 1.0. Naturalmente, la vera domanda è: dovremmo ancora gestire gli user agent HTTP 1.0 adesso?
Response.RedirectSeeOther) e se il client non è 1.1 (ad es GET /foo.html. GET /foo.html HTTP/1.0) quindi rilasciare l'eredità 302.
Un buon esempio 307 Internal Redirectdell'azione è quando Google Chrome incontra una chiamata HTTP a un dominio che conosce come esigente Sicurezza del trasporto rigorosa.
Il browser reindirizza senza problemi, utilizzando lo stesso metodo della chiamata originale.
/register-form.htmla signup-form.html./register.php, ora carica (GET) /success.html./register.php, allora questo gli dice di ripetere il POST a /signup.php.RFC 7231 (dal 2014) è molto leggibile e non eccessivamente dettagliato. Se vuoi conoscere la risposta esatta, è una lettura consigliata. Alcune altre risposte usano RFC 2616 del 1999, ma nulla è cambiato.
RFC 7238 specifica lo stato 308. È considerato sperimentale, ma era già supportato da tutti i principali browser nel 2016.
PREVISTO per 302: il reindirizzamento utilizza lo stesso metodo di richiesta POST su NEW_URL
CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT POST NEW_URL
ATTIVO per 302, 303: reindirizzare il metodo di richiesta di modifiche 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)
ATTUALE per 307: il reindirizzamento utilizza lo stesso metodo di richiesta POST su NEW_URL
CLIENT POST OLD_URL -> SERVER 307 NEW_URL -> CLIENT POST NEW_URL
302 è il reindirizzamento temporaneo, che viene generato dal server mentre 307 è la risposta di reindirizzamento interno generata dal browser. Il reindirizzamento interno significa che il reindirizzamento viene eseguito automaticamente dal browser internamente, in pratica il browser modifica l'URL immesso da http a https per ottenere la richiesta da solo prima di effettuare la richiesta, quindi la richiesta di connessione non protetta non viene mai effettuata a Internet. Il fatto che il browser cambi o meno l'URL in https dipende dall'elenco di precaricamento hsts preinstallato con il browser. Puoi anche aggiungere qualsiasi sito che supporti https all'elenco inserendo il dominio nell'elenco di precaricamento hsts del tuo browser che è in chrome: //net-internals/#hsts.Un altro dominio di siti Web può essere aggiunto dai proprietari per precaricare l'elenco compilando il modulo in https://hstspreload.org/in modo che venga preinstallato nei browser per ogni utente anche se menziono che puoi fare particolarmente anche per te stesso.
Lasciatemi spiegare con un esempio:
ho fatto una richiesta get a http://www.pentesteracademy.com che supporta solo https e non ho quel dominio nel mio elenco di precaricamento hsts sul mio browser poiché il proprietario del sito non si è registrato per questo a venire con l'elenco precaricato hsts preinstallato.
La richiesta GET per la versione non protetta del sito viene reindirizzata alla versione protetta (vedere la posizione dell'intestazione http per quella in risposta nell'immagine sopra).
Ora aggiungo il sito al mio elenco di precaricamenti del browser aggiungendo il suo dominio nel modulo Aggiungi dominio hsts su chrome: // net-internals / # hsts, che modifica il mio elenco di precarichi personali sul mio browser Chrome. Assicurati di selezionare Includi sottodomini per Opzione STS lì.
Vediamo ora la richiesta e la risposta per lo stesso sito Web dopo averlo aggiunto all'elenco di precaricamento hsts.
puoi vedere il reindirizzamento interno 307 lì nelle intestazioni di risposta, in realtà questa risposta è generata dal tuo browser non dal server.
Anche l'elenco di precaricamento HSTS può aiutare a impedire agli utenti di raggiungere la versione non sicura del sito poiché 302 reindirizzamenti sono inclini a mitigare gli attacchi.
Spero di averti aiutato in qualche modo a capire meglio i reindirizzamenti.
Inizialmente c'era solo 302
| Response | What browsers should do |
|------------------------|---------------------------|
| 302 Found | Redo request with new url |
L'idea è che:
GETin qualche posizione, dovresti rifare il tuo GETal nuovo URLPOSTin qualche posizione, dovresti rifare il tuo POSTal nuovo URLPUTin qualche posizione, dovresti rifare il tuo PUTal nuovo URLDELETEin qualche posizione, dovresti rifare il tuo DELETEal nuovo URLPurtroppo ogni browser ha sbagliato. Quando ottengono un 302, passerebbero sempre GETal nuovo URL, piuttosto che riprovare la richiesta con lo stesso verbo ( ad es . POST):
È diventato di fatto sbagliato.
Tutti i browser hanno 302sbagliato. Quindi 303e 307sono stati creati.
| Risposta | Cosa dovrebbero fare i browser | Cosa fanno effettivamente i browser | | ------------------------ | ------------------------ --- | --------------------------- | | 302 trovati | Ripeti richiesta con nuovo URL | OTTIENI con il nuovo URL | | 303 Vedi Altro | OTTIENI con il nuovo URL | OTTIENI con il nuovo URL | | 307 Reindirizzamento temporaneo | Ripeti richiesta con nuovo URL | Ripeti richiesta con nuovo URL |
I 5 diversi tipi di reindirizzamenti:
╔═══════════╤════════════════════════════════════════════════╗
║ │ Switch to GET? ║
║ Temporary │ No │ Yes ║
╠═══════════╪════════════════════════╪═══════════════════════╣
║ No │ 308 Permanent Redirect │ 301 Moved Permanently ║
╟───────────┼────────────────────────┼───────────────────────╢
║ Yes │ 307 Temporary Redirect │ 303 See Other ║
║ │ 302 Found (intended) │ 302 Found (actual) ║
╚═══════════╧════════════════════════╧═══════════════════════╝
In alternativa:
| Response | Switch to get? | Temporary? |
|--------------------------|----------------|------------|
| 301 Moved Permanently | No | No |
| 302 Found (intended) | No | Yes |
| 302 Found (actual) | Yes | Yes |
| 303 See Other | Yes | Yes |
| 307 Temporary Redirect | No | Yes |
| 308 Permanent Redirect | No | No |
Inoltre, per gli amministratori del server, potrebbe essere importante notare che i browser possono presentare una richiesta all'utente se si utilizza il reindirizzamento 307.
Ad esempio *, Firefox e Opera chiedono all'utente il permesso di reindirizzare, mentre Chrome, IE e Safari eseguono il reindirizzamento in modo trasparente.
* per SSL e TLS antiproiettile (pagina 192).
In alcuni casi d'uso, 307 reindirizzamenti potrebbero essere abusati da un utente malintenzionato per apprendere le credenziali della vittima.
Ulteriori informazioni sono disponibili nella sezione 3.1 di Un'analisi di sicurezza formale completa di OAuth 2.0 .
Gli autori del documento sopra suggeriscono quanto segue:
Fix. Contrariamente all'attuale formulazione dello 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 viene 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 preservare la richiesta POST e i dati del modulo. In pratica, i browser in genere riscrivono su una richiesta GET, eliminando così i dati del modulo, ad eccezione di 307 reindirizzamenti. Pertanto, lo standard OAuth dovrebbe richiedere 303 reindirizzamenti per i passaggi sopra menzionati per risolvere questo problema.