Frammento URL e reindirizzamenti 302

È noto che il frammento di URL (la parte dopo il # ) non viene inviato al server.

Mi chiedo però come funzionano i frammenti quando è coinvolto un reindirizzamento del server (tramite lo stato HTTP 302 e l’intestazione Location: :).

La mia domanda è davvero duplice:

  1. Se l’URL originale aveva un frammento ( /original.php#foo ), e un reindirizzamento viene fatto a /new.php , la parte frammentata dell’URL originale si perde semplicemente? O a volte viene applicato al nuovo URL?
    In questo caso il nuovo URL sarà mai /new.php#foo ?

  2. Indipendentemente dall’URL originale, se il server reindirizza a un nuovo URL con un frammento ( /new.php#foo ), il frammento verrà “onorato”? Oppure il server non ha alcun business che interferisca con il frammento – e quindi il browser lo ignorerà semplicemente andando a /new.php ?

Aggiornamento 2014-Jun-27 :

RFC 7231, Hypertext Transfer Protocol (HTTP / 1.1): semantica e contenuto , è stato pubblicato come uno STANDARD PROPOSTO. Dal Changelog :

La syntax del campo dell’intestazione Location è stata modificata per consentire tutti i riferimenti URI, inclusi riferimenti e frammenti relativi, insieme ad alcuni chiarimenti su quando l’uso dei frammenti non sarebbe appropriato. (Sezione 7.1.2)

I punti importanti della Sezione 7.1.2. Posizione :

Se il valore Location fornito in una risposta 3xx (Reindirizzamento) non ha un componente frammento, un interprete DEVE elaborare il reindirizzamento come se il valore ereditasse il componente frammento del riferimento URI usato per generare il target della richiesta (cioè, il reindirizzamento eredita il frammento del riferimento originale, se presente).

Ad esempio, una richiesta GET generata per il riferimento URI ” http://www.example.org/~tim ” potrebbe generare una risposta 303 (Vedi Altro) contenente il campo dell’intestazione:

 Location: /People.html#tim 

il che suggerisce che l’agente utente reindirizzi a ” http://www.example.org/People.html#tim

Allo stesso modo, una richiesta GET generata per il riferimento URI ” http://www.example.org/index.html#larry ” potrebbe comportare una risposta 301 (Spostata in modo permanente) contenente il campo dell’intestazione:

 Location: http://www.example.net/index.html 

il che suggerisce che l’agente utente reindirizzi a ” http://www.example.net/index.html#larry “, preservando l’identificatore del frammento originale.

Questo dovrebbe chiaramente rispondere alle tue domande.

Aggiorna END

questo è un problema aperto (non specificato) con le specifiche HTTP correnti . è affrontato in 2 numeri del gruppo di lavoro httpbis IETF :

  • # 6: Frammenti permessi in posizione
  • # 43: combinazione di frammenti / precedenza durante i reindirizzamenti

# 6 consente i frammenti nell’intestazione Location . # 43 dice questo:

Ho appena provato questo con vari browser.

  • Firefox e Safari utilizzano il frammento nell’intestazione della posizione.
  • Opera usa il frammento dall’URI sorgente, quando presente, altrimenti il ​​frammento dalla posizione di reindirizzamento
  • IE (8) ignora il frammento nell’URI di posizione, quindi utilizzerà il frammento dall’URI di origine, quando presente

Proposta:

“Nota: il comportamento quando gli identificatori di frammento dall’URI originale e il reindirizzamento devono essere combinati non è definito, gli attuali agenti degli utenti effettivamente differiscono su quale frammento ha la precedenza.”

[…]

Sembra che IE8 usi il frammento idenfitier da Location (il comportamento che ho visto potrebbe essere limitato a localhost).

Sembra quindi che abbiamo un comportamento coerente per Safari / IE / Firefox / Chrome (appena testato), in quanto viene utilizzato il frammento dell’intestazione Location, indipendentemente dall’originale URI.

Pertanto cambio la mia proposta per documentare ciò come comportamento atteso.

questo porta alla maggior parte dei browser compatibili e a prova di futuro (perché questo problema verrà alla fine standardizzato) rispondere alla tua domanda:

A: i frammenti degli URL originali vengono scartati.

B: i frammenti dell’intestazione Location sono onorati.

Safari 5 e IE9 e versioni precedenti rilasciano il frammento dell’URI originale se si verifica un reindirizzamento HTTP / 3xx. Se l’intestazione Location della risposta specifica un frammento, viene utilizzato.

IE10 +, Chrome 11+, Firefox 4+ e Opera ricominceranno a “riattaccare” il frammento dell’URI originale dopo aver seguito un reindirizzamento 3xx.

Pagina di test: http://www.webdbg.com/test/redir/fragment/ .

Vedi ulteriori discussioni su questo problema su http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx

Solo per farti sapere, qui puoi trovare le specifiche appropriate. di w3c che definisce come dovrebbero comportarsi tutti: http://www.w3.org/TR/cuap#uri – clausola 4.1 – vedi sotto:

Quando una risorsa (URI1) è stata spostata, un reindirizzamento HTTP può indicare la sua nuova posizione (URI2).

Se URI1 ha un identificatore di frammento #frag, la nuova destinazione che l’agente utente dovrebbe tentare di raggiungere sarebbe URI2 # frag. Se URI2 ha già un identificatore di frammento, allora #frag non deve essere aggiunto e il nuovo target è URI2.

Sbagliato: la maggior parte degli agenti utente attuali implementano i reindirizzamenti HTTP ma non aggiungono l’identificatore di frammento al nuovo URI, che generalmente confonde l’utente perché finisce con la risorsa sbagliata.

Riferimenti:

I reindirizzamenti HTTP sono descritti nella sezione 10.3 della specifica HTTP / 1.1 [RFC2616]. Il comportamento richiesto è descritto in dettaglio in “Gestione degli identificativi dei frammenti negli URL reindirizzati” [RURL]. Il termine “Persistent Uniform Resource Locator (PURL)” designa un URL (un caso speciale di un URI) che punta a un altro tramite un reindirizzamento HTTP. Per ulteriori informazioni, consultare “Persistent Uniform Resource Locators” [PURL]. Esempio:

Supponiamo che un utente richieda la risorsa su http://www.w3.org/TR/WD-ruby/#changes e che il server reindirizzi l’agente utente a http://www.w3.org/TR/ruby/ . Prima di recuperare quest’ultimo URI, il browser deve aggiungere l’identificativo del frammento #changes ad esso: http://www.w3.org/TR/ruby/#changes .