php - 解析 WWW URL 前缀的不同方法

Question

似乎最普遍接受的重定向用户的方法是http://example.com至 http://www.example.com是通过 301 永久重定向，但我遇到了一个似乎正在使用其他方法重定向的网站 (Facebook)。 我使用了 PHP 内置的 get_headers() 函数，它显示了 http://facebook.com和 http://www.facebook.com当我希望看到两个不同的 HTTP 代码(类似于 200 OK 和 301 永久重定向)时，返回 302(已找到)。那么，如果 facebook.com 重定向到 www.facebook.com，为什么我会看到相同的 HTTP 响应代码？他们可以使用哪些其他方法(不包括明显的方法，如元刷新等)来重定向？

以下是使用和不使用 WWW 前缀测试 get_headers() 的两个数据数组:

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

如果您使用 https://facebook.com/(第 1 步)而没有使用 www，首先 Facebook 会将您重定向到 https://www .facebook.com/(第 2 步)，然后检查您的浏览器(第 3 步；它检查您的用户代理:如果您使用 curl，请放置典型的浏览器用户代理，如 Chrome):如果浏览器不支持它将您重定向到 http://www.facebook.com/unsupportedbrowser(第 4 步)。但是，如果您直接使用 https://www.facebook.com/，即您从第 2 步开始，那么它会立即检查您的浏览器(第 3 步)以及是否不受支持它只是将您重定向到 http://www.facebook.com/unsupportedbrowser(第 4 步)。

此页面解释了 HTTP 状态代码定义

(我记下了我认为是您正在寻找的答案的文字)

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.