2011-11-30 13 views
17

Mi chiedo quale codice di stato HTTP dovrei inviare nei reindirizzamenti di lingua.Codice di stato HTTP per il reindirizzamento della lingua

Ho il seguente codice php per reindirizzare tramite le intestazioni HTTP alla lingua più importante nell'intestazione del browser Accept-Language.

<? 
$langs = array(); 

if (isset($_SERVER['HTTP_ACCEPT_LANGUAGE'])) { 
    // break up string into pieces (languages and q factors) 
    preg_match_all('/([a-z]{1,8}(-[a-z]{1,8})?)\s*(;\s*q\s*=\s*(1|0\.[0-9]+))?/i', $_SERVER['HTTP_ACCEPT_LANGUAGE'], $lang_parse); 

    if (count($lang_parse[1])) { 
     // create a list like "en" => 0.8 
     $langs = array_combine($lang_parse[1], $lang_parse[4]); 

     // set default to 1 for any without q factor 
     foreach ($langs as $lang => $val) { 
      if ($val === '') $langs[$lang] = 1; 
     } 

     // sort list based on value 
     arsort($langs, SORT_NUMERIC); 
    } 
} 

// look through sorted list and use first one that matches our languages 
foreach ($langs as $lang => $val) { 
    if (strpos($lang, 'ca')===0) { 
    header("location: ca/"); 
    exit; 
    } else if (strpos($lang, 'es')===0) { 
    header("location: es/"); 
    exit; 
    } 
    echo "$lang => $val<br>"; 
} 
// show default site or prompt for language 
header("location: en/"); 

?> 

questione connessa: HTTP status for functional redirect

Forse 300, 301, 302, 303? Perché?

EDIT

Google ha recentemente pubblicato questo: http://googlewebmastercentral.blogspot.com/2011/12/new-markup-for-multilingual-content.html

ho trovato questo:

HTTP STATUS 300 Multiple Choices

La risorsa richiesta corrisponde a uno qualsiasi di una set di rappresentazioni , ciascuna con le proprie specifiche La posizione geografica e le informazioni di negoziazione dell'agente- (sezione 12) vengono fornite in modo che l'utente (o l'agente utente) possa selezionare una rappresentazione preferita e reindirizzare la sua richiesta a tale posizione.

A meno che non si trattava di una richiesta HEAD, la risposta dovrebbe includere un soggetto contenente un elenco di caratteristiche di risorse e posizione (s) da cui l'agente utente o utente può scegliere la più appropriata. Il formato dell'entità è specificato dal tipo di supporto indicato nel campo Content- Type. A seconda del formato e delle capacità di

l'agente utente, la selezione della scelta più appropriata può essere eseguita automaticamente. Tuttavia, questa specifica non definisce lo standard per tale selezione automatica.

Se il server ha una scelta preferita di rappresentanza, dovrebbe includere l'URI specifico per quella rappresentazione in posizione campo; user agent POSSONO utilizzare il valore del campo Location per il reindirizzamento automatico . Questa risposta è memorizzabile nella cache a meno che non sia indicato diversamente.

E questo:

errore HTTP 300 - Scelte multiple

Introduzione

Il server Web pensa che l'URL fornito dal cliente (ad esempio, il browser Web o il nostro CheckUpDown robot) non è abbastanza specifico, e una selezione ulteriore deve essere fatta da un numero di scelte.

Questo è in genere il caso in cui l'URL rappresenta un gruppo di livello elevato di cui è necessario effettuare selezioni di livello inferiore, ad es. una directory all'interno della quale l'utente deve selezionare un determinato file per l'accesso a .

300 errori nel ciclo HTTP

Qualsiasi client (ad esempio il Web browser o il nostro robot CheckUpDown) passa attraverso il seguente ciclo quando si comunica con il server Web:

Ottieni un indirizzo IP dal Nome IP del sito (l'URL del sito senza il prefisso 'http: //'). Questa ricerca (conversione del nome IP nell'indirizzo IP ) viene fornita dai DNS (Domain Name Server). Aprire una connessione socket IP a quell'indirizzo IP. Scrivi un flusso di dati HTTP attraverso tale socket. Ricevere un flusso di dati HTTP dal server Web in risposta. Questo flusso di dati contiene codici di stato i cui valori sono determinati dal protocollo HTTP. Analizzare questo flusso di dati per i codici di stato e altre informazioni utili. Questo errore si verifica nel passaggio finale precedente quando il client riceve un codice di stato HTTP che è riconosciuto come "300".

fissaggio 300 errori - generali

La prima cosa da fare è controllare il vostro URL in un browser Web. Se si vede una sorta di pagina Web che richiede ulteriori azioni , allora l'URL così com'è non è sufficientemente dettagliato per il server Web da elaborare per .

fissaggio 300 errori - CheckUpDown

Non si dovrebbe mai vedere questo errore sul vostro conto CheckUpDown se ci ha dato un URL di primo livello (come ad esempio www.isp.com) per controllare. Se si verifica per un URL di livello superiore, è altamente probabile che il software del server Web sia stato programmato o configurato in modo errato. Se hai dato un URL di basso livello (come www.isp.com/products/index.html) al controllo , è probabile che questo URL non sia accessibile anche tramite un browser Web .

La prima cosa che dovresti fare è controllare l'URL in un browser web. Se si vede una pagina Web ragionevole, allora potrebbe indicare un difetto nel nostro software . Se tuttavia vedi qualche tipo di pagina Web che ti chiede di effettuare ulteriori azioni/scelte, il tuo URL non è adatto per noi, perché il nostro sistema non può fare questo tipo di scelta.

Si prega di contattarci direttamente (e-mail preferito) ogni volta che si verificano errori 300. Solo noi possiamo risolverli per te. Se c'è un difetto nel nostro software , lo ripareremo. Se tuttavia il tuo URL è fondamentalmente inadatto per noi per l'uso di , devi modificarlo sul tuo account CheckUpDown (inizia con facendo clic sul pulsante "Gestisci").

risposta

0

HTTP 303, perché ha la formulazione più adatta. Vedere Altro (302 spostati temporaneamente e 301 spostati in modo permanente). In realtà la risposta HTTP 303 in questa situazione per garantire che il browser dell'utente Web possa quindi aggiornare in modo sicuro la risposta del server senza causare la richiesta di POST HTTP iniziale.

+1

di tutte le scelte, 303 è quella che è sicuramente corretto. Ad esempio, se si esegue il PUT su una risorsa negoziata, non si desidera che la libreria HTTP modifichi la richiesta in GET dopo il reindirizzamento. –

1

Possibilmente HTTP 300 "Multiple Choices" poiché tecnicamente è lo stesso documento/dati ma è disponibile in più lingue?

+0

Penso che tu abbia ragione. –

+2

Il codice di stato 300 deve essere utilizzato per rispondere con un documento che elenca tutte le scelte se la negoziazione non è riuscita. – Gumbo

+0

Sì - ma non è quello che si sta facendo (guardando il codice)? Se la lingua viene rilevata automaticamente da HTTP_ACCEPT_LANGUAGE, faremo così - altrimenti c'è un commento che dice '// mostra sito predefinito o prompt per lingua' ... è stato quel bit" prompt for language "che mi ha fatto pensare che 300 sarebbero stati "giusto" ... anche se, come quasi tutto nella programmazione, ci sono sempre più valori per "giusto";) – CD001

1

penso che le domande sono più legati ciò che si vuole raggiungere:

1: La vostra pagina di indice dovrebbe essere la pagina di destinazione per il visitatore, e si desidera che la pagina l'essere indicizzato dai motori di ricerca.

Pro: si dispone di una pagina di accesso per tutti i visitatori che possono ospitare ulteriori informazioni prima della pagina di destinazione effettiva. Tuttavia, non avrà contenuto per una lingua specifica.

Contro: Non ci sono pagine di contenuti per tutte le lingue sui motori di ricerca.

2: La pagina tradotta effettiva dovrebbe essere la pagina di destinazione e, se possibile, i visitatori dovrebbero finire direttamente nella pagina tradotta, se possibile. La pagina di reindirizzamento è solo per i visitatori che sono finiti direttamente sul tuo sito inserendo il nome host nella barra degli indirizzi.

Pro: hai più "pagine di destinazione" per ogni singola lingua, che aiuta a fare punti e click-through.

Contro: Non hai una pagina di destinazione generica.

Ci sono più pro e contro su queste due scelte, ma non riesco a pensarci adesso.

Se opzione 1: utilizzare un 302 perché si desidera ancora che faccia parte dell'indice di ricerca. se opzione 2: utilizzare un 301 perché non si desidera che la pagina venga indicizzata. In alternativa, usa un noindex nella pagina di selezione della lingua.

Afaik, Google prende in considerazione solo 301, 302 e 307 (manutenzione temporanea), e penso che consideri tutto il resto come 302 (sembra più logico). Per quanto riguarda il browser, penso che non importi. Potrebbe influire sul caching, ma penso che al giorno d'oggi siano piuttosto aggressivi nel caching anche delle risposte 3xx.

+0

Desidero che ogni pagina della lingua sia indicizzata in ciascun indice di ricerca della lingua. (es. Cerca in spagnolo restituisce/es /, cerca in inglese return/en /). Pensi che dovrei avere/come home page per la lingua predefinita? Dovrei usare rel = canonical allora? – jrosell

+0

È possibile utilizzare canonica per questo se si desidera, ma non necessariamente. Se reindirizza sempre i visitatori a/en con un 301, Google indicizzerà solo gli URL di lingua. – jishi

+0

Pensi che abbia senso avere 301 in base alla negoziazione dei contenuti? – jrosell

4

È possibile servire tutte le lingue con lo stesso url e quindi utilizzare la negoziazione del contenuto dell'intestazione Accept-Language, ma non lo consiglierei.

Vorrei piuttosto suggerire che sul proprio URL radice del sito Web, si emette un reindirizzamento (303 - Vedere Altro) in una sotto-pagina della lingua (ad esempio /en). Quando si esegue questa operazione, rispondere con un'intestazione Vary, che specifica Accept-Language (e qualsiasi altra intestazione rilevante, ad esempio Cookie). In questo modo, qualsiasi intermediario (proxy, cache) sarà in grado di memorizzare nella cache la risposta. Vorrei specificamente non emettere un 301, poiché desideri ancora che i collegamenti puntino all'URL di root. Nella pagina specifica della lingua, inserisco un rel="canonical" nell'URL radice.

Vedi anche questi fili:

+0

Analizzerò questi 2 collegamenti, ma per ora ... È possibile generare un elenco di "Location header per ogni lingua" e lasciare che il browser decida? – jrosell

+0

Il browser ha già deciso, in qualche modo, di inviare una lista prioritaria nella richiesta (l'intestazione 'Accept-Language'). L'intestazione di risposta 'Vary: Accept-Language' specifica che questa era la base della decisione. – troelskn

+0

Sei sicuro che un'intestazione Vary sia necessaria? Non vedo alcun sito multilingua che risponde con l'intestazione Varia-Language Accept. – Jordy

4

Google utilizza 302 Found per il reindirizzamento alla pagina localizzata.

Penso che sia sicuro se Google lo utilizza ...

Tuttavia, è sempre bene controllare che cosa selezionato risposta dovrebbe fare e ciò che esso è destinato ad e influisce caching:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Problemi correlati