Http Error Code 301
Contents |
Status codes 301 Moved Permanently 302 Found 303 See Other 403 Forbidden 404 Not Found 451 Unavailable For Legal Reasons http code 302 v t e The HTTP response status code 301 Moved Permanently
301 Moved Permanently Nginx
is used for permanent URL redirection, meaning current links or records using the URL that the response 301 moved permanently curl is received for should be updated. The new URL should be provided in the Location field included with the response. The 301 redirect is considered a best http status code practice for upgrading users from HTTP to HTTPS.[1] RFC 2616 states that: If a client has link-editing capabilities, it should update all references to the Request URL. The response is cachable.[2] Unless the request method was HEAD, the entity should contain a small hypertext note with a hyperlink to the new URL(s). If the
Http 301 Vs 302
301 status code is received in response to a request of any type other than GET or HEAD, the client must ask the user before redirecting. Contents 1 Example 1.1 Search engines 2 See also 3 References Example[edit] Client request: GET /index.php HTTP/1.1 Host: www.example.org Server response: HTTP/1.1 301 Moved Permanently Location: http://www.example.org/index.asp Here is an example using an htaccess file to redirect to a non www with an SSL attached to the domain. RewriteEngine On RewriteCond %{HTTPS} off RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] RewriteRule ^(.*)$ http://%1/$1 [R=301,L] RewriteCond %{HTTPS} on RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] RewriteRule ^(.*)$ https://%1/$1 [R=301,L] RewriteEngine On RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://example.com/$1 [R,L] Here is an example using a PHP redirect. Equivalently simple for an nginx configuration. location /old/url/ { return 301 /new/url; } Search engines[edit] Both Bing and Google recommend using a 301 redirect to change the URL of a page as it is shown in search engin
referer DNT X-Forwarded-For Status codes 301 Moved Permanently 302 Found 303 See Other 403 Forbidden 404 Not Found 451 Unavailable For Legal Reasons v t e This is a list of Hypertext Transfer Protocol http status codes cheat sheet (HTTP) response status codes. It includes codes from IETF internet standards, other IETF http 403 RFCs, other specifications, and some additional commonly used codes. The first digit of the status code specifies one of five classes
Http Response Example
of response; an HTTP client must recognise these five classes at a minimum. The phrases used are the standard wordings, but any human-readable alternative can be provided. Unless otherwise stated, the status code is https://en.wikipedia.org/wiki/HTTP_301 part of the HTTP/1.1 standard (RFC 7231).[1] The Internet Assigned Numbers Authority (IANA) maintains the official registry of HTTP status codes.[2] Microsoft IIS sometimes uses additional decimal sub-codes to provide more specific information,[3] but not all of those are here (note that these sub-codes only appear in the response payload and in documentation; not in the place of an actual HTTP status code). Contents 1 1xx Informational 2 https://en.wikipedia.org/wiki/List_of_HTTP_status_codes 2xx Success 3 3xx Redirection 4 4xx Client Error 5 5xx Server Error 6 Unofficial codes 6.1 Internet Information Services 6.2 nginx 6.3 Cloudflare 7 See also 8 Notes 9 References 10 External links 1xx Informational[edit] Request received, continuing process. This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. Since HTTP/1.0 did not define any 1xx status codes, servers must not[note 1] send a 1xx response to an HTTP/1.0 client except under experimental conditions.[4] 100 Continue The server has received the request headers and the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). Sending a large request body to a server after a request has been rejected for inappropriate headers would be inefficient. To have a server check the request's headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. The response 417 Expectation Failed indicates the request should not be continued.[2] 101 Switching Protocols The requester has asked the se
- general The 301 response from the Web server should always include an alternative URL to which redirection should occur. If it does, a Web browser will immediately retry the alternative http://www.checkupdown.com/status/E301.html URL. So you never actually see a 301 error in a Web browser, unless perhaps you have a corrupt redirection chain e.g. URL A redirects to URL B which in turn redirects back to URL A. If your client is not a Web browser, it should behave in the same way as a Web browser i.e. immediately retry the alternative URL. If the Web server does not return an 301 moved alternative URL with the 301 response, then either the Web server software itself is defective or the Webmaster has not set up the URL redirection correctly. Fixing 301 errors - CheckUpDown Redirection of URLs may occur for low-level URLs (specific URLs within the Web site such as www.isp.com/products/index.html) when you reorganise the web site, but is relatively uncommon for top-level URLs (such as www.isp.com) which most users specify 301 moved permanently for their CheckUpDown accounts. So this error should be fairly infrequent. The 301 response from the Web server should always include an alternative URL to which redirection should occur. If it does, CheckUpDown automatically tries the alternative URL. This in turn may possibly lead to another redirection which CheckUpDown then tries. This continues for a maximum of 5 redirections. As soon as 5 redirections have occurred, CheckUpDown gives up and reports the 301 error for your account. So you should only ever see the 301 error if 1) the Web server gives no alternative URL on the 301 response or 2) the number of redirections exceeds 5. This second condition should be fairly unlikely - and may indicate a recursive pattern e.g. URL A redirects to URL B which in turn redirects back to URL A. You first need to check that the IP name we use to check for your account is accurate. If you or your ISP have configured something so that any access using this name should now be permanently redirected to another name, then you need to update your CheckUpDown account to start using the new name. If you believe that the IP name we use is exact (should n