Different ways of resolving the WWW URL prefix

Question

It seems that the most commonly accepted method of redirecting users from http://example.com to http://www.example.com is by 301 Permanent redirect, but I came across a site(Facebook) that appears to be redirecting using some other method. I used PHP's built in get_headers() function which reveals that both http://facebook.com and http://www.facebook.com return 302 (Found), when I expected to see two different HTTP codes (something like a 200 OK and 301 Permanent Redirect). So why am I seeing the same HTTP response code if facebook.com redirects to www.facebook.com? What other methods could they be using (excluding obvious methods like meta refresh, etc.) to redirect?

Here are both arrays of data from testing get_headers() with and without the WWW prefix:

Array
(
[0] => HTTP/1.0 302 Found
[1] => Location: https://facebook.com/
[2] => Content-Type: text/html; charset=utf-8
[3] => X-FB-Debug: wwltbGRu1BTbywd3gta2SdLc+wpyGdq51OOfn2wGKPs=
[4] => Date: Tue, 30 Apr 2013 06:46:59 GMT
[5] => Connection: close
[6] => Content-Length: 0
[7] => HTTP/1.0 301 Moved Permanently
[8] => Location: https://www.facebook.com/
[9] => Content-Type: text/html; charset=utf-8
[10] => X-FB-Debug: WxvPFmdvhZu01Ksi4H9ttx0nffFCraY9TQtxscHgRlU=
[11] => Date: Tue, 30 Apr 2013 06:47:00 GMT
[12] => Connection: close
[13] => Content-Length: 0
[14] => HTTP/1.0 302 Found
[15] => Location: http://www.facebook.com/unsupportedbrowser
[16] => P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
[17] => X-Content-Type-Options: nosniff
[18] => Set-Cookie: datr=5Gh_Ue6q0jyzse8jKRbcPg2N; expires=Thu, 30-Apr-2015 06:47:00 GMT; path=/; domain=.facebook.com; httponly
[19] => Content-Type: text/html; charset=utf-8
[20] => X-FB-Debug: 3lKH0JMHOjd/q5qzs0s6h+WJdk0YnQG67DhnqJa7D3Q=
[21] => Date: Tue, 30 Apr 2013 06:47:00 GMT
[22] => Connection: close
[23] => Content-Length: 0
[24] => HTTP/1.0 200 OK
[25] => Cache-Control: private, no-cache, no-store, must-revalidate
[26] => Expires: Sat, 01 Jan 2000 00:00:00 GMT
[27] => P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
[28] => Pragma: no-cache
[29] => X-Content-Type-Options: nosniff
[30] => X-Frame-Options: DENY
[31] => X-XSS-Protection: 0
[32] => Set-Cookie: datr=5Gh_URQUdhoRh4w74JHDNmtA; expires=Thu, 30-Apr-2015 06:47:00 GMT; path=/; domain=.facebook.com; httponly
[33] => Set-Cookie: reg_ext_ref=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.facebook.com
[34] => Set-Cookie: reg_fb_gate=http%3A%2F%2Fwww.facebook.com%2Funsupportedbrowser; path=/; domain=.facebook.com
[35] => Set-Cookie: reg_fb_ref=http%3A%2F%2Fwww.facebook.com%2Funsupportedbrowser; path=/; domain=.facebook.com
[36] => Content-Type: text/html; charset=utf-8
[37] => X-FB-Debug: poI8PSRn+KNx3GnMc+8ZcZzsWFncr28gewEWkLisCbc=
[38] => Date: Tue, 30 Apr 2013 06:47:00 GMT
[39] => Connection: close
[40] => Content-Length: 19409
)
Array
(
[0] => HTTP/1.0 302 Found
[1] => Location: https://www.facebook.com/
[2] => Content-Type: text/html; charset=utf-8
[3] => X-FB-Debug: duXMWSWa3Fr5k98z6Ze/HkXeYG5qY8tRuhvCEXg/6wQ=
[4] => Date: Tue, 30 Apr 2013 06:47:00 GMT
[5] => Connection: close
[6] => Content-Length: 0
[7] => HTTP/1.0 302 Found
[8] => Location: http://www.facebook.com/unsupportedbrowser
[9] => P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
[10] => X-Content-Type-Options: nosniff
[11] => Set-Cookie: datr=5Wh_UUqT6BOIQhG3lvSCTnUI; expires=Thu, 30-Apr-2015 06:47:01 GMT; path=/; domain=.facebook.com; httponly
[12] => Content-Type: text/html; charset=utf-8
[13] => X-FB-Debug: B7P9WpeO6QRPr3g+7D/b6w3ssnJMGVa3AXd3qaG6UOA=
[14] => Date: Tue, 30 Apr 2013 06:47:01 GMT
[15] => Connection: close
[16] => Content-Length: 0
[17] => HTTP/1.0 200 OK
[18] => Cache-Control: private, no-cache, no-store, must-revalidate
[19] => Expires: Sat, 01 Jan 2000 00:00:00 GMT
[20] => P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
[21] => Pragma: no-cache
[22] => X-Content-Type-Options: nosniff
[23] => X-Frame-Options: DENY
[24] => X-XSS-Protection: 0
[25] => Set-Cookie: datr=5Wh_Ud4XwmSGX2Uxzg_KAHgW; expires=Thu, 30-Apr-2015 06:47:01 GMT; path=/; domain=.facebook.com; httponly
[26] => Set-Cookie: reg_ext_ref=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.facebook.com
[27] => Set-Cookie: reg_fb_gate=http%3A%2F%2Fwww.facebook.com%2Funsupportedbrowser; path=/; domain=.facebook.com
[28] => Set-Cookie: reg_fb_ref=http%3A%2F%2Fwww.facebook.com%2Funsupportedbrowser; path=/; domain=.facebook.com
[29] => Content-Type: text/html; charset=utf-8
[30] => X-FB-Debug: 4HXkUp4MHgy+i8qppuZvbHhYH6F4xQlfl0mUNrpj5hY=
[31] => Date: Tue, 30 Apr 2013 06:47:01 GMT
[32] => Connection: close
[33] => Content-Length: 19409
)

Answer 1

If you come with https://facebook.com/ (step 1) without www, at first Facebook redirects you to https://www.facebook.com/ (step 2), then checks for your browser (step 3; it checks your user agent: if you use curl put a typical browser user agent like Chrome): if the browser is not supported it redirects you to http://www.facebook.com/unsupportedbrowser (step 4). But if you come directly with https://www.facebook.com/, that is you start at the step 2, then it immediately checks for your browser (step 3) and if it is not supported it just redirects you to http://www.facebook.com/unsupportedbrowser (step 4).

This page explains HTTP Status Code Definitions

(I noted down the text I think is the answer you are searching for)

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

10.3.2 301 Moved Permanently

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

  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 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

  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 it were a 303
  response, performing a GET on the Location field-value regardless
  of the original request method. The status codes 303 and 307 have
  been added for servers that wish to make unambiguously clear which
  kind of reaction is expected of the client.