Quando un utente non ha effettuato l'accesso e tenta di accedere a una pagina che richiede l'accesso, qual è il codice di stato HTTP corretto per un reindirizzamento alla pagina di accesso?
Lo sto chiedendo perché nessuno dei codici di risposta 3xx stabiliti dal W3C sembra soddisfare i requisiti:
10.3.1 300 scelte multiple
La risorsa richiesta corrisponde a una qualsiasi di una serie di rappresentazioni, ognuna con la propria posizione specifica e vengono fornite informazioni di negoziazione guidate dall'agente (sezione 12) in modo che l'utente (o agente utente) possa selezionare una rappresentazione preferita e reindirizzare la sua richiesta in quella posizione.
A meno che non si trattasse di una richiesta HEAD, la risposta DOVREBBE includere un'entità contenente un elenco di caratteristiche e ubicazioni delle risorse da cui l'utente o l'agente utente possono scegliere quello più appropriato. Il formato dell'entità è specificato dal tipo di supporto indicato nel campo di intestazione Tipo di contenuto. A seconda del formato e delle capacità di
l'agente utente, la selezione della scelta più appropriata PUO 'essere eseguita automaticamente. Tuttavia, questa specifica non definisce alcuno standard per tale selezione automatica.
Se il server ha una scelta preferita di rappresentazione, DOVREBBE includere l'URI specifico per quella rappresentazione nel campo Posizione; i programmi utente POSSONO utilizzare il valore del campo Posizione per il reindirizzamento automatico. Questa risposta è memorizzabile nella cache se non diversamente indicato.
10.3.2 301 spostato in modo permanente
Alla risorsa richiesta è stato assegnato un nuovo URI permanente e qualsiasi riferimento futuro a questa risorsa DOVREBBE utilizzare uno degli URI restituiti. I client con funzionalità di modifica dei collegamenti dovrebbero ricollegare automaticamente i riferimenti all'URI della richiesta a uno o più dei nuovi riferimenti restituiti dal server, ove possibile. Questa risposta è memorizzabile nella cache se non diversamente indicato.
Il nuovo URI permanente DOVREBBE essere indicato dal campo Posizione nella risposta. A meno che il metodo di richiesta non sia HEAD, l'entità della risposta DOVREBBE contenere una breve nota ipertestuale con un collegamento ipertestuale ai nuovi URI.
Se il codice di stato 301 viene ricevuto in risposta a una richiesta diversa da GET o HEAD, l'agente utente NON DEVE reindirizzare automaticamente la richiesta a meno che non possa essere confermata dall'utente, poiché ciò potrebbe modificare le condizioni in cui la richiesta è stata emessa.
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.10.3.3 302 trovati
La risorsa richiesta risiede temporaneamente con un URI diverso. Poiché il reindirizzamento potrebbe essere modificato in determinate occasioni, il client DOVREBBE continuare a utilizzare l'URI della richiesta per richieste future. Questa risposta è memorizzabile nella cache solo se indicata da un campo di intestazione Controllo cache o Scadenza.
L'URI temporaneo DOVREBBE essere indicato dal campo Posizione nella risposta. A meno che il metodo di richiesta non sia HEAD, l'entità della risposta DOVREBBE contenere una breve nota ipertestuale con un collegamento ipertestuale ai nuovi URI.
Se il codice di stato 302 viene ricevuto in risposta a una richiesta diversa da GET o HEAD, l'agente utente NON DEVE reindirizzare automaticamente la richiesta a meno che non possa essere confermata dall'utente, poiché ciò potrebbe modificare le condizioni in cui è stata emessa la richiesta.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if iterano una risposta 303, eseguendo un OTTENERE 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 quale tipo di reazione è prevista per il client.
10.3.4 303 Vedi Altro
La risposta alla richiesta può essere trovata sotto un URI diverso e DOVREBBE essere recuperata utilizzando un metodo GET su quella risorsa. Questo metodo esiste principalmente per consentire all'output di uno script attivato POST di reindirizzare l'agente utente su una risorsa selezionata. Il nuovo URI non è un riferimento sostitutivo per la risorsa richiesta originariamente. La risposta 303 NON DEVE essere memorizzata nella cache, ma la risposta alla seconda richiesta (reindirizzata) potrebbe essere memorizzabile nella cache.
Il diverso URI DOVREBBE essere indicato dal campo Posizione nella risposta. A meno che il metodo di richiesta non sia HEAD, l'entità della risposta DOVREBBE contenere una breve nota ipertestuale con un collegamento ipertestuale ai nuovi URI.
Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.10.3.5 304 Non modificato
Se il client ha eseguito una richiesta GET condizionale e l'accesso è consentito, ma il documento non è stato modificato, il server DOVREBBE rispondere con questo codice di stato. La risposta 304 NON DEVE contenere un corpo di messaggio e quindi viene sempre terminata dalla prima riga vuota dopo i campi di intestazione.
La risposta DEVE includere i seguenti campi di intestazione:
- Date, unless its omission is required by section 14.18.1 If ail server di origine senza clock obbedisce a queste regole e i proxy e i client aggiungono la propria Data a qualsiasi risposta ricevuta senza una (come già specificato da [RFC 2068], sezione 14.19), le cache funzioneranno correttamente.
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant If the conditional GET used a strong cache validator (seesezione 13.3.3), la risposta NON DOVREBBE includere altre intestazioni di entità. Altrimenti (ovvero, il GET condizionale utilizzava un validatore debole), la risposta NON DEVE includere altre intestazioni di entità; questo evita incoerenze tra i corpi di entità cache e le intestazioni aggiornate.
Se una risposta 304 indica un'entità non attualmente memorizzata nella cache, la cache DEVE ignorare la risposta e ripetere la richiesta senza il condizionale.
Se una cache utilizza una risposta 304 ricevuta per aggiornare una voce della cache, la cache DEVE aggiornare la voce per riflettere eventuali nuovi valori di campo forniti nella risposta.
10.3.6 305 Usa proxy
È necessario accedere alla risorsa richiesta tramite il proxy fornito dal campo Posizione. Il campo Posizione fornisce l'URI del proxy. Il destinatario dovrebbe ripetere questa singola richiesta tramite il proxy. 305 risposte DEVONO essere generate solo dai server di origine.
Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing these limitations has significant security consequences.10.3.7 306 (Non utilizzato)
Il codice di stato 306 era utilizzato in una versione precedente della specifica, non è più utilizzato e il codice è riservato.
10.3.8 307 Reindirizzamento temporaneo
La risorsa richiesta risiede temporaneamente con un URI diverso. Poiché il reindirizzamento POTREBBE essere modificato occasionalmente, il client DOVREBBE continuare a utilizzare l'URI della richiesta per richieste future. Questa risposta è memorizzabile nella cache solo se indicata da un campo di intestazione Controllo cache o Scadenza.
L'URI temporaneo DOVREBBE essere indicato dal campo Posizione nella risposta. A meno che il metodo di richiesta non sia HEAD, l'entità della risposta DOVREBBE contenere una breve nota ipertestuale con un collegamento ipertestuale ai nuovi URI, poiché molti agenti utente pre-HTTP / 1.1 non comprendono lo stato 307. Pertanto, la nota DOVREBBE contenere le informazioni necessarie affinché un utente possa ripetere la richiesta originale sul nuovo URI.
Se il codice di stato 307 viene ricevuto in risposta a una richiesta diversa da GET o HEAD, l'agente utente NON DEVE reindirizzare automaticamente la richiesta a meno che non possa essere confermata dall'utente, poiché ciò potrebbe modificare le condizioni in cui è stata emessa la richiesta.
Sto usando 302 per ora, fino a quando non trovo la risposta corretta.
Aggiornamento e conclusione:
HTTP 302 è migliore poiché è noto per avere la migliore compatibilità con client / browser.