HTTP Status code for language redirect

Question

I wonder which HTTP Status code I should have to send in language redirects.

I have the following php code to redirect via HTTP headers to most important language in Accept-Language browser header.

<?
$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/");

?>

Related question: HTTP status for functional redirect

Maybe 300, 301, 302, 303? Why?

EDIT

Google recently published this: http://googlewebmastercentral.blogspot.com/2011/12/new-markup-for-multilingual-content.html

I found this:

HTTP STATUS 300 Multiple Choices

The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.

Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of

the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.

If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise.

And this:

HTTP Error 300 - Multiple choices

Introduction

Your Web server thinks that the URL provided by the client (e.g. your Web browser or our CheckUpDown robot) is not specific enough, and a further selection needs to be made from a number of choices.

This is typically the case where the URL represents a high level grouping of which lower level selections need to be made e.g. a directory within which the user must select a particular file to access.

300 errors in the HTTP cycle

Any client (e.g. your Web browser or our CheckUpDown robot) goes through the following cycle when it communicates with the Web server:

Obtain an IP address from the IP name of the site (the site URL without the leading 'http://'). This lookup (conversion of IP name to IP address) is provided by domain name servers (DNSs). Open an IP socket connection to that IP address. Write an HTTP data stream through that socket. Receive an HTTP data stream back from the Web server in response. This data stream contains status codes whose values are determined by the HTTP protocol. Parse this data stream for status codes and other useful information. This error occurs in the final step above when the client receives an HTTP status code that it recognises as '300'.

Fixing 300 errors - general

The first thing you should do is check your URL in a Web browser. If you see some kind of Web page prompting you for further action/choices, then your URL as it stands is not detailed enough for the Web server to process.

Fixing 300 errors - CheckUpDown

You should never see this error on your CheckUpDown account if you gave us a top-level URL (such as www.isp.com) to check. If it does occur for a top-level URL, it is highly likely that the Web server software has been incorrectly programmed or configured. If you have given us a low-level URL (such as www.isp.com/products/index.html) to check, then it is likely that this URL is not accessible even via a Web browser.

The first thing you should do is check your URL in a Web browser. If you see a sensible Web page, then it may indicate a defect in our software. If however you see some kind of Web page prompting you for further action/choices, then your URL is not suitable for us to check, because our system can not possibly make this kind of choice.

Please contact us directly (email preferred) whenever you encounter 300 errors. Only we can resolve them for you. If there is a defect in our software we will fix it. If however your URL is fundamentally unsuitable for us to use, you need to change it on your CheckUpDown account (start by clicking the 'Manage' button).

Answer 1

Google uses 302 Found for redirection to localised page.

I think it is safe if Google uses it...

However, it's always good to check what selected response should do and what it is intended for and does it affect caching:

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