308 ошибка http

Код ответа на статус перенаправления «HTTP 308 Permanent Redirect" указывает, что запрошенный ресурс был окончательно перемещён в URL-адрес, указанный в Location (en-US). Браузер перенаправляется на эту страницу, а поисковые системы обновляют свои ссылки на ресурс (в SEO-speak говорится, что link-juice отправляется на новый URL-адрес).

Метод запроса и тело не будут изменены, тогда как 301 иногда может быть неправильно заменён на GET метод.

Примечание: Некоторые веб-приложения могут использовать 308 Permanent Redirect нестандартным образом и для других целей. Например, Google Drive использует ответ 308 Resume Incomplete, чтобы указать клиенту, когда неполная загрузка застопорилась.[1]

Статус

Характеристики

Спецификации	Название
RFC 7538, секция 3: 308 Permanent Redirect	The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)

Совместимость с браузером

BCD tables only load in the browser

Смотрите также

• 301 Moved Permanently
• 302 Found, the temporary redirect

Jan 11, 2018 6:00:19 PM |
308 Permanent Redirect: What It Is and How to Fix It

A close look at the 308 Permanent Redirect response code, including troubleshooting tips to help you resolve this error in your own application.

A 308 Permanent Redirect message is an HTTP response status code indicating that the requested resource has been permanently moved to another URI, as indicated by the special Location header returned within the response. The 308 Permanent Redirect code was added to the HTTP standard relatively recently in April 2015, as detailed in the RFC7538 specification document for the 308 status code. As written in the RFC specification, the 308 Permanent Redirect code was necessary to fill in the gap left with similar codes of 301, 302, and 307.

There are dozens of possible HTTP status codes used to represent the complex relationship between the client, a web application, a web server, and the multitude of third-party web services that may be in use, so determining the cause of a particular HTTP response status code can be difficult. Since there are so many potential codes, each of which represents a completely different status or event, it can be difficult to differentiate between many of them and determine the exact cause of such errors, including the 308 Permanent Redirect response code.

Throughout this article we’ll explore the 308 Permanent Redirect code by looking at a handful of troubleshooting tips. We’ll also examine a few useful and easy to implement fixes for common problems that could be causing 308 codes to appear in your own web application. Let’s get down to it!

The Problem is Server-Side

All HTTP response status codes within the 3xx category are considered redirection messages. These codes indicate to the user agent (i.e. your web browser) that an additional action is required in order to complete the request and access the desired resource. The 3xx response code category is distinctly different from the 5xx codes category, which encompasses server error messages. For example, the 503 Service Unavailable error we explored a late last year indicates that a server is temporarily unavailable, or is unable to handle the request for some reason. Thus, while a 5xx category code indicates an actual problem has occurred on a server, a 3xx category code, such as 308 Permanent Redirect, is rarely indicative of an actual problem — it merely occurs due to the server’s behavior or configuration, but is not indicative of an error or bug on the server.

The 308 Permanent Redirect code is similar to the 301 Moved Permanently code we explore in our 301 Moved Permanently: What It Is and How to Fix It article. As discussed in that post, the RFC1945 HTTP/1.0 specification document explicitly states that the 301 code should not necessarily inform user agents (i.e. browsers) to automatically redirect POST HTTP method requests to GET HTTP method requests. However, many user agents did erroneously change POST requests to GET redirect requests, which led to unintentional problems.

To handle this explicit allowance or denial of changing POST requests to GET requests the HTTP standards included the following codes:

• 301 Moved Permanently: The resource has been permanently moved and request method conversion from POST to GET is allowed.
• 307 Temporary Redirect: The resource has been temporarily moved and request method conversion from POST to GET is forbidden.
• 302 Found: The resource has been temporarily moved and request method conversion from POST to GET is allowed.

As you can see, this set of three HTTP status codes is missing a code that indicates a permanent redirect that forbids POST to GET conversion. This is the exact role that the 308 Permanent Redirect status code fulfills.

The appearance of a 308 Permanent Redirect is usually not something that requires much user intervention. All modern browsers will automatically detect the 308 Permanent Redirect response code and process the redirection action to the new URI automatically. The server sending a 308 code will also include a special Location header as part of the response it sends to the client. This Location header indicates the new URI where the requested resource can be found. For example, if an HTTP POST method request is sent by the client as an attempt to login at the https://airbrake.io URL, the web server may be configured to redirect this POST request to a different URI, such as https://airbrake.io/login. In this scenario, the server may respond with a 308 Permanent Redirect code and include the Location: https://airbrake.io/login header in the response. This informs the user agent (browser) that the POST request data (login info) was received by the server, but the resource has been permanently moved to the Location header URI of https://airbrake.io/login.

It’s also important to distinguish the purpose and use-cases of the 308 Permanent Redirect response code from many seemingly similar 3xx codes, such as the 307 Temporary Redirect we looked at in the past. The 307 Temporary Redirect code informs the client that the passed Location URI is only a temporary resource, and that all future requests should continue to access the originally requested URI. On the other hand, the 308 Permanent Redirect message is permanent and indicates that the passed Location URI should be used for future (identical) requests.

Additionally, since the 308 Permanent Redirect indicates that something has gone wrong within the server of your application, we can largely disregard the client side of things. If you’re trying to diagnose an issue with your own application, you can immediately ignore most client-side code and components, such as HTML, cascading style sheets (CSS), client-side JavaScript, and so forth. This doesn’t apply solely to web sites, either. Many smart phone apps that have a modern looking user interface are actually powered by a normal web application behind the scenes; one that is simply hidden from the user. If you’re using such an application and a 308 Permanent Redirect occurs, the issue isn’t going to be related to the app installed on your phone or local testing device. Instead, it will be something on the server-side, which is performing most of the logic and processing behind the scenes, outside the purview of the local interface presented to the user.

If your application is generating unexpected 308 Permanent Redirect response codes there are a number of steps you can take to diagnose the problem, so we’ll explore a few potential work around below.

Start With a Thorough Application Backup

As with anything, it’s better to have played it safe at the start than to screw something up and come to regret it later on down the road. As such, it is critical that you perform a full backup of your application, database, and so forth, before attempting any fixes or changes to the system. Even better, if you have the capability, create a complete copy of the application onto a secondary staging server that isn’t «live,» or isn’t otherwise active and available to the public. This will give you a clean testing ground with which to test all potential fixes to resolve the issue, without threatening the security or sanctity of your live application.

Diagnosing a 308 Permanent Redirect Response Code

A 308 Permanent Redirect response code indicates that the requested resource has been permanently moved to the new URI specified in the Location response header. However, the appearance of this error itself may be erroneous, as it’s entirely possible that the server is misconfigured, which could cause it to improperly respond with 308 Permanent Redirect codes, instead of the standard and expected 200 OK code seen for most successful requests. Thus, a large part of diagnosing the issue will be going through the process of double-checking what resources/URLs are generating 308 Permanent Redirect response codes and determining if these codes are appropriate or not.

If your application is responding with 308 Permanent Redirect codes that it should not be issuing, this is a problem that many other visitors may be experiencing as well, dramatically hindering your application’s ability to service users. We’ll go over some troubleshooting tips and tricks to help you try to resolve this issue. If nothing here works, don’t forget to try Googling for the answer. Search for specific terms related to your issue, such as the name of your application’s CMS or web server software, along with 308 Permanent Redirect. Chances are you’ll find others who have experienced this issue and have (hopefully) found a solution.

Troubleshooting on the Server-Side

Here are some additional tips to help you troubleshoot what might be causing the 308 Permanent Redirect to appear on the server-side of things:

Confirm Your Server Configuration

Your application is likely running on a server that is using one of the two most popular web server softwares, Apache or nginx. At the time of publication, both of these web servers make up over 84% of the world’s web server software! Thus, one of the first steps you can take to determine what might be causing these 308 Permanent Redirect response codes is to check the configuration files for your web server software for unintentional redirect instructions.

To determine which web server your application is using you’ll want to look for a key file. If your web server is Apache then look for an .htaccess file within the root directory of your website file system. For example, if your application is on a shared host you’ll likely have a username associated with the hosting account. In such a case, the application root directory is typically found at the path of /home/<username>/public_html/, so the .htaccess file would be at /home/<username>/public_html/.htaccess.

If you located the .htaccess file then open it in a text editor and look for lines that use RewriteXXX directives, which are part of the mod_rewrite module in Apache. Covering exactly how these rules work is well beyond the scope of this article, however, the basic concept is that a RewriteCond directive defines a text-based pattern that will be matched against entered URLs. If a matching URL is requested by a visitor to the site, the RewriteRule directive that follows one or more RewriteCond directives is used to perform the actual redirection of the request to the appropriate URL.

For example, here is a simple RewriteCond and RewriteRule combination that matches all incoming requests to airbrake.io using the HTTP POST method, and redirecting them to https://airbrake.io/login via a 308 Permanent Redirect response:

RewriteEngine on

RewriteCond %{HTTP_HOST} ^airbrake.io$

RewriteRule ^(.*)$ https://airbrake.io/login$1 [R=308]

Notice the extra flag at the end of the RewriteRule, which explicitly states that the response code should be 308, indicating to user agents that the request should be repeated to the specified URI, but while retaining the original HTTP method (POST, in this case). Thus, if you find any strange RewriteCond or RewriteRule directives in the .htaccess file that don’t seem to belong, try temporarily commenting them out (using the # character prefix) and restarting your web server to see if this resolves the issue.

On the other hand, if your server is running on nginx, you’ll need to look for a completely different configuration file. By default this file is named nginx.conf and is located in one of a few common directories: /usr/local/nginx/conf, /etc/nginx, or /usr/local/etc/nginx. Once located, open nginx.conf in a text editor and look for return or rewrite directives that are using the 308 response code flag. For example, here is a simple block directive (i.e. a named set of directives) that configures a virtual server by creating a redirection from airbrake.io to airbrake.io/login for POST HTTP method requests:

server {

    listen 80;

    listen 443 ssl;

    server_name airbrake.io;

    if ($request_method = POST) {

        return 308 https://airbrake.io/login$request_uri;

    }

}

Return directives in nginx are similar to the RewriteCond and RewriteRule directives found in Apache, as they tend to contain more complex text-based patterns for searching. Either way, look through your nginx.conf file for any abnormal return or rewrite directives that include the 308 flag. Comment out any abnormalities before restarting the server to see if the issue was resolved.

Scour the Logs

Nearly every web application will keep some form of server-side logs. Application logs are typically the history of what the application did, such as which pages were requested, which servers it connected to, which database results it provides, and so forth. Server logs are related to the actual hardware that is running the application, and will often provide details about the health and status of all connected services, or even just the server itself. Google «logs [PLATFORM_NAME]» if you’re using a CMS, or «logs [PROGRAMMING_LANGUAGE]» and «logs [OPERATING_SYSTEM]» if you’re running a custom application, to get more information on finding the logs in question.

Debug Your Application Code

If all else fails, it may be that a problem in some custom code within your application is causing the issue. Try to diagnose where the issue may be coming from through manually debugging your application, along with parsing through application and server logs. Ideally, make a copy of the entire application to a local development machine and perform a step-by-step debug process, which will allow you to recreate the exact scenario in which the 308 Permanent Redirect occurred and view the application code at the moment something goes wrong.

No matter what the cause, the appearance of a 308 Permanent Redirect within your own web application is a strong indication that you may need an error management tool to help you automatically detect such errors in the future. The best of these tools can even alert you and your team immediately when an error occurs. Airbrake’s error monitoring software provides real-time error monitoring and automatic exception reporting for all your development projects. Airbrake’s state of the art web dashboard ensures you receive round-the-clock status updates on your application’s health and error rates. No matter what you’re working on, Airbrake easily integrates with all the most popular languages and frameworks. Plus, Airbrake makes it easy to customize exception parameters, while giving you complete control of the active error filter system, so you only gather the errors that matter most.

Check out Airbrake’s error monitoring software today and see for yourself why so many of the world’s best engineering teams use Airbrake to revolutionize their exception handling practices!

What exactly is a 308 Permanent Redirect, and how do you fix 308 error code? Here’s how to handle the status code without causing more harm to your site.

You’ve probably heard about 301 redirects if you own a website. Have you ever encountered a status code of 308 Permanent Redirect?

These are less well-known, yet they may be equally important to your marketing efforts.

Here’s all you need to know about the 308 Permanent Redirect status code, as well as tried-and-true solutions for correcting it without causing more harm to your website.

>>> Hire the Best Mobile App Development Companies 

What Is a 308 Permanent Redirect and How Does It Work?

Before we get right into how to fix 308 error code, let’s discuss what it is and how it works. 

Similar to 301 Moved Permanently, 308 Permanent Redirect indicates that the resource the user attempted to access has moved to a different URI.

The 308 is a relatively new code that was just introduced to the RFC7238 specification to fill the void left by codes like 301, 302, and 307.

>>> Learn how to Fix 408 Error Code 

Is This a Client-Side Error?

Let’s have a look at how the internet works before we answer this question.

On the internet, there are two key players: servers and clients.

Assume you’re using your browser to access a website. You’re using a web client to connect to the internet.

With your request to access the web page, the web client sends a message to the server. When you make a request to your server to access a resource, the server responds with an HTTP status code.

A successful request, a client error, or a server error are all possible status codes. In actuality, there are five different types of HTTP response status codes:

• Status codes 1xx: Requests for information
• 2xx status codes indicate that the request was successful.
• Redirects are represented by the 3xx status codes.
• 4xx codes of status: Errors by clients
• Server failures are indicated by the 5xx status codes.

Despite their differences, they all inform a user whether a certain HTTP request has been completed successfully.

The 308 Permanent Redirect that we’re investigating today is part of the 3xx status codes or redirects group. Some of the status codes in the category, such as 301 Moved Permanently and 307 Temporary Redirect, might have a direct impact on your site’s user experience and SEO health.

In comparison, status codes in the 4xx group – such as the 404 Not Found error – indicate a problem on the client side. The 5xx status codes, on the other hand, indicate that the issue is caused by anything on the server side of things.

We can completely disregard the client-side of things because the 308 Permanent Redirect indicates a problem on the server side.

>>> Error Playing Content 403 Forbidden: How To Fix

What Is the Difference Between Redirects 301, 302, 307, and 308?

Let’s understand the differences of each before we get into how to fix 308 error code.

One of the most prevalent redirects is the 301 redirect. It signifies that the resource has been transferred permanently and that change of the request method from POST to GET is permitted. If you want to permanently redirect a moved or deleted page, or if the structure of your permalinks has changed, you should use this redirect. To avoid a 404 error, always add a 301 redirect to your removed or moved pages.

302 Found: A 302 redirect is a one-time redirect that sends visitors and search engines to a different page for a set period of time. It indicates that the resource has been moved temporarily and that conversion of the request method from POST to GET is permitted. When you’re rebuilding or changing your website, use this redirect.

307 Temporary Redirect: The HTTP 1.1 successor to 302 redirects is the 307 Temporary Redirect. It indicates that the resource has been moved temporarily and that converting the request method from POST to GET is prohibited.

As you can see from the list above, this collection of codes is missing a status code that signals a permanent redirect that prevents the conversion of POST to GET. The 308 status code serves this purpose.

>>> Err_Ssl_Protocol_Error WordPress: How To Fix?

What Is a 308 Permanent Redirect Response Code and How to Fix 308 Error Code?

If your website is returning a 308 Permanent Redirect response code, follow these steps to diagnose and resolve the problem.

Make a Complete Backup of your Application.

This suggestion is more of a piece of safety advise than a code-fixing method. You must make a replica of your website on a secondary server that isn’t online or otherwise active if you don’t want to further damage it.

Before you try to remedy the problem and update the system, make a complete backup. This creates a safe environment in which you may test all potential fixes without jeopardizing the security of your live application.

Ensure that your Server is Configured Correctly.

The first real advice on the list is to examine your web server’s configuration files for any unintended redirect instructions.

Your application is served by one of two web servers: Apache or Nginx. If it’s running on an Apache server, make sure apache server and.htaccess are both checked.

If you’re using Nginx, you only need to verify one file: nginx conf_. After you’ve found the files, look for a 308 status code and see what comes up. If it does, you must change it. If you don’t require the status code, you may either remove it totally or apply it to a single page.

>>> Hire the best Software Development Companies 

Troubleshoot Your Application Code

Probably one of the best ways to fix 308 error code is to troubleshoot your app code. Server-side logs are kept by almost every web application. The history of what the application did while running a website is frequently stored in application logs.

If the troubleshooting step above didn’t solve the problem, the issue could be due to custom code in your application.

You must manually debug your application code to discover if this is the case. When something goes wrong, go through a step-by-step troubleshooting process to replicate the exact scenario that caused the 308 Permanent Redirect and see the application code.

>>> How to Resolve HTTP Error 508 WordPress Sites

Final Thoughts

The 308 Permanent Redirect status code indicates that the user’s requested resource has moved to a different URI.

The best technique to fix 308 error code is to: 

Verify your server’s settings.

Debug the code in your application.

You should invest in a reliable website maintenance solution to assist you automatically spot such mistakes in the future to avoid status codes severely influencing your user experience and SEO performance. Exai, for example, can detect an issue as soon as it arises. You can rest assured that your website is current and completely functional, allowing you to maintain a strong online presence.

If you are in need of professional help, connect with the best website development companies at Distinguished.io today. 

---

---

An IETF RFC draft The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect) defines HTTP status 308 as Permanent Redirect. It should, of course, be noted that this is a draft document and contains in its document header the text «Expires: September 27, 2012», which I presume would mean it should be considered invalid now, but I’m not familiar with IETF’s processes and so don’t feel confident about this.

The Wikipedia article List of HTTP status codes uses this definition of 308, also:

308 Permanent Redirect (approved as experimental RFC)^[12]

The request, and all future requests should be repeated using another URI. 307 and 308 (as proposed) parallel the behaviours of 302 and 301, but do not allow the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.

…

[12]: «The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)». IETF. 2012. Retrieved March 27, 2012.

Eric Law, of Microsoft at the time, comments on this HTTP/308 code in Pushing the Web Forward with HTTP/308. That caused me to discover that Firefox supports 308 under this meaning.

However, when I was looking in the python-requests library, I found that there is another usage of 308:

    308: ('resume_incomplete', 'resume'),

This seems to come from a Google Gears resumable HTTP requests proposal, defining 308 Resume Incomplete. There seems to be some usage of that. Of course, neither of these proposals acknowledges the existence of the other.

So what’s going on? Is 308 Permanent Redirect alive? What’s happening with the status code 308? What should I do?

From Wikipedia, the free encyclopedia

(Redirected from 202 Accepted)

This is a list of Hypertext Transfer Protocol (HTTP) response status codes. Status codes are issued by a server in response to a client’s request made to the server. It includes codes from IETF Request for Comments (RFCs), other specifications, and some additional codes used in some common applications of the HTTP. The first digit of the status code specifies one of five standard classes of responses. The optional message phrases shown are typical, but any human-readable alternative may be provided, or none at all.

Unless otherwise stated, the status code is part of the HTTP standard (RFC 9110).

The Internet Assigned Numbers Authority (IANA) maintains the official registry of HTTP status codes.^[1]

All HTTP response status codes are separated into five classes or categories. The first digit of the status code defines the class of response, while the last two digits do not have any classifying or categorization role. There are five classes defined by the standard:

• 1xx informational response – the request was received, continuing process
• 2xx successful – the request was successfully received, understood, and accepted
• 3xx redirection – further action needs to be taken in order to complete the request
• 4xx client error – the request contains bad syntax or cannot be fulfilled
• 5xx server error – the server failed to fulfil an apparently valid request

1xx informational response

An informational response indicates that the request was received and understood. It is issued on a provisional basis while request processing continues. It alerts the client to wait for a final response. The message consists only of the status line and optional header fields, and is terminated by an empty line. As the HTTP/1.0 standard did not define any 1xx status codes, servers must not^{[note 1]} send a 1xx response to an HTTP/1.0 compliant client except under experimental conditions.

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. If the client receives an error code such as 403 (Forbidden) or 405 (Method Not Allowed) then it should not send the request’s body. The response 417 Expectation Failed indicates that the request should be repeated without the Expect header as it indicates that the server does not support expectations (this is the case, for example, of HTTP/1.0 servers).^[2]

101 Switching Protocols

The requester has asked the server to switch protocols and the server has agreed to do so.

102 Processing (WebDAV; RFC 2518)

A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet.^[3] This prevents the client from timing out and assuming the request was lost.

103 Early Hints (RFC 8297)

Used to return some response headers before final HTTP message.^[4]

2xx success

This class of status codes indicates the action requested by the client was received, understood, and accepted.^[1]

200 OK

Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request, the response will contain an entity describing or containing the result of the action.

201 Created

The request has been fulfilled, resulting in the creation of a new resource.^[5]

202 Accepted

The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.

203 Non-Authoritative Information (since HTTP/1.1)

The server is a transforming proxy (e.g. a Web accelerator) that received a 200 OK from its origin, but is returning a modified version of the origin’s response.^[6][7]

204 No Content

The server successfully processed the request, and is not returning any content.

205 Reset Content

The server successfully processed the request, asks that the requester reset its document view, and is not returning any content.

206 Partial Content

The server is delivering only part of the resource (byte serving) due to a range header sent by the client. The range header is used by HTTP clients to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.

207 Multi-Status (WebDAV; RFC 4918)

The message body that follows is by default an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.^[8]

208 Already Reported (WebDAV; RFC 5842)

The members of a DAV binding have already been enumerated in a preceding part of the (multistatus) response, and are not being included again.

226 IM Used (RFC 3229)

The server has fulfilled a request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.^[9]

3xx redirection

This class of status code indicates the client must take additional action to complete the request. Many of these status codes are used in URL redirection.^[1]

A user agent may carry out the additional action with no user interaction only if the method used in the second request is GET or HEAD. A user agent may automatically redirect a request. A user agent should detect and intervene to prevent cyclical redirects.^[10]

300 Multiple Choices

Indicates multiple options for the resource from which the client may choose (via agent-driven content negotiation). For example, this code could be used to present multiple video format options, to list files with different filename extensions, or to suggest word-sense disambiguation.

301 Moved Permanently

This and all future requests should be directed to the given URI.

302 Found (Previously «Moved temporarily»)

Tells the client to look at (browse to) another URL. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect with the same method (the original describing phrase was «Moved Temporarily»),^[11] but popular browsers implemented 302 redirects by changing the method to GET. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours.^[10]

303 See Other (since HTTP/1.1)

The response to the request can be found under another URI using the GET method. When received in response to a POST (or PUT/DELETE), the client should presume that the server has received the data and should issue a new GET request to the given URI.

304 Not Modified

Indicates that the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match. In such case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.

305 Use Proxy (since HTTP/1.1)

The requested resource is available only through a proxy, the address for which is provided in the response. For security reasons, many HTTP clients (such as Mozilla Firefox and Internet Explorer) do not obey this status code.

306 Switch Proxy

No longer used. Originally meant «Subsequent requests should use the specified proxy.»

307 Temporary Redirect (since HTTP/1.1)

In this case, the request should be repeated with another URI; however, future requests should still use the original URI. In contrast to how 302 was historically implemented, the request method is not allowed to be changed when reissuing the original request. For example, a POST request should be repeated using another POST request.

308 Permanent Redirect

This and all future requests should be directed to the given URI. 308 parallel the behaviour of 301, but does not allow the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.

4xx client errors

This class of status code is intended for situations in which the error seems to have been caused by the client. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents should display any included entity to the user.

400 Bad Request

The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, size too large, invalid request message framing, or deceptive request routing).

401 Unauthorized

Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication. 401 semantically means «unauthorised», the user does not have valid authentication credentials for the target resource.

Some sites incorrectly issue HTTP 401 when an IP address is banned from the website (usually the website domain) and that specific address is refused permission to access a website.^{[citation needed]}

402 Payment Required

Reserved for future use. The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, as proposed, for example, by GNU Taler,^[13] but that has not yet happened, and this code is not widely used. Google Developers API uses this status if a particular developer has exceeded the daily limit on requests.^[14] Sipgate uses this code if an account does not have sufficient funds to start a call.^[15] Shopify uses this code when the store has not paid their fees and is temporarily disabled.^[16] Stripe uses this code for failed payments where parameters were correct, for example blocked fraudulent payments.^[17]

403 Forbidden

The request contained valid data and was understood by the server, but the server is refusing action. This may be due to the user not having the necessary permissions for a resource or needing an account of some sort, or attempting a prohibited action (e.g. creating a duplicate record where only one is allowed). This code is also typically used if the request provided authentication by answering the WWW-Authenticate header field challenge, but the server did not accept that authentication. The request should not be repeated.

404 Not Found

The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.

405 Method Not Allowed

A request method is not supported for the requested resource; for example, a GET request on a form that requires data to be presented via POST, or a PUT request on a read-only resource.

406 Not Acceptable

The requested resource is capable of generating only content not acceptable according to the Accept headers sent in the request. See Content negotiation.

407 Proxy Authentication Required

The client must first authenticate itself with the proxy.

408 Request Timeout

The server timed out waiting for the request. According to HTTP specifications: «The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.»

409 Conflict

Indicates that the request could not be processed because of conflict in the current state of the resource, such as an edit conflict between multiple simultaneous updates.

410 Gone

Indicates that the resource requested was previously in use but is no longer available and will not be available again. This should be used when a resource has been intentionally removed and the resource should be purged. Upon receiving a 410 status code, the client should not request the resource in the future. Clients such as search engines should remove the resource from their indices. Most use cases do not require clients and search engines to purge the resource, and a «404 Not Found» may be used instead.

411 Length Required

The request did not specify the length of its content, which is required by the requested resource.

412 Precondition Failed

The server does not meet one of the preconditions that the requester put on the request header fields.

413 Payload Too Large

The request is larger than the server is willing or able to process. Previously called «Request Entity Too Large» in RFC 2616.^[18]

414 URI Too Long

The URI provided was too long for the server to process. Often the result of too much data being encoded as a query-string of a GET request, in which case it should be converted to a POST request. Called «Request-URI Too Long» previously in RFC 2616.^[19]

415 Unsupported Media Type

The request entity has a media type which the server or resource does not support. For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.

416 Range Not Satisfiable

The client has asked for a portion of the file (byte serving), but the server cannot supply that portion. For example, if the client asked for a part of the file that lies beyond the end of the file. Called «Requested Range Not Satisfiable» previously RFC 2616.^[20]

417 Expectation Failed

The server cannot meet the requirements of the Expect request-header field.^[21]

418 I’m a teapot (RFC 2324, RFC 7168)

This code was defined in 1998 as one of the traditional IETF April Fools’ jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. The RFC specifies this code should be returned by teapots requested to brew coffee.^[22] This HTTP status is used as an Easter egg in some websites, such as Google.com’s «I’m a teapot» easter egg.^[23][24][25] Sometimes, this status code is also used as a response to a blocked request, instead of the more appropriate 403 Forbidden.^[26][27]

421 Misdirected Request

The request was directed at a server that is not able to produce a response (for example because of connection reuse).

422 Unprocessable Entity

The request was well-formed but was unable to be followed due to semantic errors.^[8]

423 Locked (WebDAV; RFC 4918)

The resource that is being accessed is locked.^[8]

424 Failed Dependency (WebDAV; RFC 4918)

The request failed because it depended on another request and that request failed (e.g., a PROPPATCH).^[8]

425 Too Early (RFC 8470)

Indicates that the server is unwilling to risk processing a request that might be replayed.

426 Upgrade Required

The client should switch to a different protocol such as TLS/1.3, given in the Upgrade header field.

428 Precondition Required (RFC 6585)

The origin server requires the request to be conditional. Intended to prevent the ‘lost update’ problem, where a client GETs a resource’s state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.^[28]

429 Too Many Requests (RFC 6585)

The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.^[28]

431 Request Header Fields Too Large (RFC 6585)

The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large.^[28]

451 Unavailable For Legal Reasons (RFC 7725)

A server operator has received a legal demand to deny access to a resource or to a set of resources that includes the requested resource.^[29] The code 451 was chosen as a reference to the novel Fahrenheit 451 (see the Acknowledgements in the RFC).

5xx server errors

The server failed to fulfil a request.

Response status codes beginning with the digit «5» indicate cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and indicate whether it is a temporary or permanent condition. Likewise, user agents should display any included entity to the user. These response codes are applicable to any request method.

500 Internal Server Error

A generic error message, given when an unexpected condition was encountered and no more specific message is suitable.

501 Not Implemented

The server either does not recognize the request method, or it lacks the ability to fulfil the request. Usually this implies future availability (e.g., a new feature of a web-service API).

502 Bad Gateway

The server was acting as a gateway or proxy and received an invalid response from the upstream server.

503 Service Unavailable

The server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state.^[30]

504 Gateway Timeout

The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.

505 HTTP Version Not Supported

The server does not support the HTTP version used in the request.

506 Variant Also Negotiates (RFC 2295)

Transparent content negotiation for the request results in a circular reference.^[31]

507 Insufficient Storage (WebDAV; RFC 4918)

The server is unable to store the representation needed to complete the request.^[8]

508 Loop Detected (WebDAV; RFC 5842)

The server detected an infinite loop while processing the request (sent instead of 208 Already Reported).

510 Not Extended (RFC 2774)

Further extensions to the request are required for the server to fulfill it.^[32]

511 Network Authentication Required (RFC 6585)

The client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g., «captive portals» used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot).^[28]

Unofficial codes

The following codes are not specified by any standard.

419 Page Expired (Laravel Framework)

Used by the Laravel Framework when a CSRF Token is missing or expired.

420 Method Failure (Spring Framework)

A deprecated response used by the Spring Framework when a method has failed.^[33]

420 Enhance Your Calm (Twitter)

Returned by version 1 of the Twitter Search and Trends API when the client is being rate limited; versions 1.1 and later use the 429 Too Many Requests response code instead.^[34] The phrase «Enhance your calm» comes from the 1993 movie Demolition Man, and its association with this number is likely a reference to cannabis.^{[citation needed]}

430 Request Header Fields Too Large (Shopify)

Used by Shopify, instead of the 429 Too Many Requests response code, when too many URLs are requested within a certain time frame.^[35]

450 Blocked by Windows Parental Controls (Microsoft)

The Microsoft extension code indicated when Windows Parental Controls are turned on and are blocking access to the requested webpage.^[36]

498 Invalid Token (Esri)

Returned by ArcGIS for Server. Code 498 indicates an expired or otherwise invalid token.^[37]

499 Token Required (Esri)

Returned by ArcGIS for Server. Code 499 indicates that a token is required but was not submitted.^[37]

509 Bandwidth Limit Exceeded (Apache Web Server/cPanel)

The server has exceeded the bandwidth specified by the server administrator; this is often used by shared hosting providers to limit the bandwidth of customers.^[38]

529 Site is overloaded

Used by Qualys in the SSLLabs server testing API to signal that the site can’t process the request.^[39]

530 Site is frozen

Used by the Pantheon Systems web platform to indicate a site that has been frozen due to inactivity.^[40]

598 (Informal convention) Network read timeout error

Used by some HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.^[41]

599 Network Connect Timeout Error

An error used by some HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.

Internet Information Services

Microsoft’s Internet Information Services (IIS) web server expands the 4xx error space to signal errors with the client’s request.

440 Login Time-out

The client’s session has expired and must log in again.^[42]

449 Retry With

The server cannot honour the request because the user has not provided the required information.^[43]

451 Redirect

Used in Exchange ActiveSync when either a more efficient server is available or the server cannot access the users’ mailbox.^[44] The client is expected to re-run the HTTP AutoDiscover operation to find a more appropriate server.^[45]

IIS sometimes uses additional decimal sub-codes for more specific information,^[46] however these sub-codes only appear in the response payload and in documentation, not in the place of an actual HTTP status code.

nginx

The nginx web server software expands the 4xx error space to signal issues with the client’s request.^[47][48]

444 No Response

Used internally^[49] to instruct the server to return no information to the client and close the connection immediately.

494 Request header too large

Client sent too large request or too long header line.

495 SSL Certificate Error

An expansion of the 400 Bad Request response code, used when the client has provided an invalid client certificate.

496 SSL Certificate Required

An expansion of the 400 Bad Request response code, used when a client certificate is required but not provided.

497 HTTP Request Sent to HTTPS Port

An expansion of the 400 Bad Request response code, used when the client has made a HTTP request to a port listening for HTTPS requests.

499 Client Closed Request

Used when the client has closed the request before the server could send a response.

Cloudflare

Cloudflare’s reverse proxy service expands the 5xx series of errors space to signal issues with the origin server.^[50]

520 Web Server Returned an Unknown Error

The origin server returned an empty, unknown, or unexpected response to Cloudflare.^[51]

521 Web Server Is Down

The origin server refused connections from Cloudflare. Security solutions at the origin may be blocking legitimate connections from certain Cloudflare IP addresses.

522 Connection Timed Out

Cloudflare timed out contacting the origin server.

523 Origin Is Unreachable

Cloudflare could not reach the origin server; for example, if the DNS records for the origin server are incorrect or missing.

524 A Timeout Occurred

Cloudflare was able to complete a TCP connection to the origin server, but did not receive a timely HTTP response.

525 SSL Handshake Failed

Cloudflare could not negotiate a SSL/TLS handshake with the origin server.

526 Invalid SSL Certificate

Cloudflare could not validate the SSL certificate on the origin web server. Also used by Cloud Foundry’s gorouter.

527 Railgun Error

Error 527 indicates an interrupted connection between Cloudflare and the origin server’s Railgun server.^[52]

530

Error 530 is returned along with a 1xxx error.^[53]

AWS Elastic Load Balancer

Amazon’s Elastic Load Balancing adds a few custom return codes

460

Client closed the connection with the load balancer before the idle timeout period elapsed. Typically when client timeout is sooner than the Elastic Load Balancer’s timeout.^[54]

463

The load balancer received an X-Forwarded-For request header with more than 30 IP addresses.^[54]

561 Unauthorized

An error around authentication returned by a server registered with a load balancer. You configured a listener rule to authenticate users, but the identity provider (IdP) returned an error code when authenticating the user.^[55]

Caching warning codes (obsoleted)

The following caching related warning codes were specified under RFC 7234. Unlike the other status codes above, these were not sent as the response status in the HTTP protocol, but as part of the «Warning» HTTP header.^[56][57]

Since this «Warning» header is often neither sent by servers nor acknowledged by clients, this header and its codes were obsoleted by the HTTP Working Group in 2022 with RFC 9111.^[58]

110 Response is Stale

The response provided by a cache is stale (the content’s age exceeds a maximum age set by a Cache-Control header or heuristically chosen lifetime).

111 Revalidation Failed

The cache was unable to validate the response, due to an inability to reach the origin server.

112 Disconnected Operation

The cache is intentionally disconnected from the rest of the network.

113 Heuristic Expiration

The cache heuristically chose a freshness lifetime greater than 24 hours and the response’s age is greater than 24 hours.

199 Miscellaneous Warning

Arbitrary, non-specific warning. The warning text may be logged or presented to the user.

214 Transformation Applied

Added by a proxy if it applies any transformation to the representation, such as changing the content encoding, media type or the like.

299 Miscellaneous Persistent Warning

Same as 199, but indicating a persistent warning.

See also

• Custom error pages
• List of FTP server return codes
• List of HTTP header fields
• List of SMTP server return codes
• Common Log Format

Explanatory notes

References

External links

• «RFC 9110: HTTP Semantics and Content, Section 15 «Status Codes»«.
• Hypertext Transfer Protocol (HTTP) Status Code Registry

From Wikipedia, the free encyclopedia

(Redirected from 202 Accepted)

This is a list of Hypertext Transfer Protocol (HTTP) response status codes. Status codes are issued by a server in response to a client’s request made to the server. It includes codes from IETF Request for Comments (RFCs), other specifications, and some additional codes used in some common applications of the HTTP. The first digit of the status code specifies one of five standard classes of responses. The optional message phrases shown are typical, but any human-readable alternative may be provided, or none at all.

Unless otherwise stated, the status code is part of the HTTP standard (RFC 9110).

The Internet Assigned Numbers Authority (IANA) maintains the official registry of HTTP status codes.^[1]

All HTTP response status codes are separated into five classes or categories. The first digit of the status code defines the class of response, while the last two digits do not have any classifying or categorization role. There are five classes defined by the standard:

• 1xx informational response – the request was received, continuing process
• 2xx successful – the request was successfully received, understood, and accepted
• 3xx redirection – further action needs to be taken in order to complete the request
• 4xx client error – the request contains bad syntax or cannot be fulfilled
• 5xx server error – the server failed to fulfil an apparently valid request

1xx informational response

An informational response indicates that the request was received and understood. It is issued on a provisional basis while request processing continues. It alerts the client to wait for a final response. The message consists only of the status line and optional header fields, and is terminated by an empty line. As the HTTP/1.0 standard did not define any 1xx status codes, servers must not^{[note 1]} send a 1xx response to an HTTP/1.0 compliant client except under experimental conditions.

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. If the client receives an error code such as 403 (Forbidden) or 405 (Method Not Allowed) then it should not send the request’s body. The response 417 Expectation Failed indicates that the request should be repeated without the Expect header as it indicates that the server does not support expectations (this is the case, for example, of HTTP/1.0 servers).^[2]

101 Switching Protocols

The requester has asked the server to switch protocols and the server has agreed to do so.

102 Processing (WebDAV; RFC 2518)

A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet.^[3] This prevents the client from timing out and assuming the request was lost.

103 Early Hints (RFC 8297)

Used to return some response headers before final HTTP message.^[4]

2xx success

This class of status codes indicates the action requested by the client was received, understood, and accepted.^[1]

200 OK

Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request, the response will contain an entity describing or containing the result of the action.

201 Created

The request has been fulfilled, resulting in the creation of a new resource.^[5]

202 Accepted

The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.

203 Non-Authoritative Information (since HTTP/1.1)

The server is a transforming proxy (e.g. a Web accelerator) that received a 200 OK from its origin, but is returning a modified version of the origin’s response.^[6][7]

204 No Content

The server successfully processed the request, and is not returning any content.

205 Reset Content

The server successfully processed the request, asks that the requester reset its document view, and is not returning any content.

206 Partial Content

The server is delivering only part of the resource (byte serving) due to a range header sent by the client. The range header is used by HTTP clients to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.

207 Multi-Status (WebDAV; RFC 4918)

The message body that follows is by default an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.^[8]

208 Already Reported (WebDAV; RFC 5842)

The members of a DAV binding have already been enumerated in a preceding part of the (multistatus) response, and are not being included again.

226 IM Used (RFC 3229)

The server has fulfilled a request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.^[9]

3xx redirection

This class of status code indicates the client must take additional action to complete the request. Many of these status codes are used in URL redirection.^[1]

A user agent may carry out the additional action with no user interaction only if the method used in the second request is GET or HEAD. A user agent may automatically redirect a request. A user agent should detect and intervene to prevent cyclical redirects.^[10]

300 Multiple Choices

Indicates multiple options for the resource from which the client may choose (via agent-driven content negotiation). For example, this code could be used to present multiple video format options, to list files with different filename extensions, or to suggest word-sense disambiguation.

301 Moved Permanently

This and all future requests should be directed to the given URI.

302 Found (Previously «Moved temporarily»)

Tells the client to look at (browse to) another URL. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect with the same method (the original describing phrase was «Moved Temporarily»),^[11] but popular browsers implemented 302 redirects by changing the method to GET. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours.^[10]

303 See Other (since HTTP/1.1)

The response to the request can be found under another URI using the GET method. When received in response to a POST (or PUT/DELETE), the client should presume that the server has received the data and should issue a new GET request to the given URI.

304 Not Modified

Indicates that the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match. In such case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.

305 Use Proxy (since HTTP/1.1)

The requested resource is available only through a proxy, the address for which is provided in the response. For security reasons, many HTTP clients (such as Mozilla Firefox and Internet Explorer) do not obey this status code.

306 Switch Proxy

No longer used. Originally meant «Subsequent requests should use the specified proxy.»

307 Temporary Redirect (since HTTP/1.1)

In this case, the request should be repeated with another URI; however, future requests should still use the original URI. In contrast to how 302 was historically implemented, the request method is not allowed to be changed when reissuing the original request. For example, a POST request should be repeated using another POST request.

308 Permanent Redirect

This and all future requests should be directed to the given URI. 308 parallel the behaviour of 301, but does not allow the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.

4xx client errors

This class of status code is intended for situations in which the error seems to have been caused by the client. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents should display any included entity to the user.

400 Bad Request

The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, size too large, invalid request message framing, or deceptive request routing).

401 Unauthorized

Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication. 401 semantically means «unauthorised», the user does not have valid authentication credentials for the target resource.

Some sites incorrectly issue HTTP 401 when an IP address is banned from the website (usually the website domain) and that specific address is refused permission to access a website.^{[citation needed]}

402 Payment Required

Reserved for future use. The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, as proposed, for example, by GNU Taler,^[13] but that has not yet happened, and this code is not widely used. Google Developers API uses this status if a particular developer has exceeded the daily limit on requests.^[14] Sipgate uses this code if an account does not have sufficient funds to start a call.^[15] Shopify uses this code when the store has not paid their fees and is temporarily disabled.^[16] Stripe uses this code for failed payments where parameters were correct, for example blocked fraudulent payments.^[17]

403 Forbidden

The request contained valid data and was understood by the server, but the server is refusing action. This may be due to the user not having the necessary permissions for a resource or needing an account of some sort, or attempting a prohibited action (e.g. creating a duplicate record where only one is allowed). This code is also typically used if the request provided authentication by answering the WWW-Authenticate header field challenge, but the server did not accept that authentication. The request should not be repeated.

404 Not Found

The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.

405 Method Not Allowed

A request method is not supported for the requested resource; for example, a GET request on a form that requires data to be presented via POST, or a PUT request on a read-only resource.

406 Not Acceptable

The requested resource is capable of generating only content not acceptable according to the Accept headers sent in the request. See Content negotiation.

407 Proxy Authentication Required

The client must first authenticate itself with the proxy.

408 Request Timeout

The server timed out waiting for the request. According to HTTP specifications: «The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.»

409 Conflict

Indicates that the request could not be processed because of conflict in the current state of the resource, such as an edit conflict between multiple simultaneous updates.

410 Gone

Indicates that the resource requested was previously in use but is no longer available and will not be available again. This should be used when a resource has been intentionally removed and the resource should be purged. Upon receiving a 410 status code, the client should not request the resource in the future. Clients such as search engines should remove the resource from their indices. Most use cases do not require clients and search engines to purge the resource, and a «404 Not Found» may be used instead.

411 Length Required

The request did not specify the length of its content, which is required by the requested resource.

412 Precondition Failed

The server does not meet one of the preconditions that the requester put on the request header fields.

413 Payload Too Large

The request is larger than the server is willing or able to process. Previously called «Request Entity Too Large» in RFC 2616.^[18]

414 URI Too Long

The URI provided was too long for the server to process. Often the result of too much data being encoded as a query-string of a GET request, in which case it should be converted to a POST request. Called «Request-URI Too Long» previously in RFC 2616.^[19]

415 Unsupported Media Type

The request entity has a media type which the server or resource does not support. For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.

416 Range Not Satisfiable

The client has asked for a portion of the file (byte serving), but the server cannot supply that portion. For example, if the client asked for a part of the file that lies beyond the end of the file. Called «Requested Range Not Satisfiable» previously RFC 2616.^[20]

417 Expectation Failed

The server cannot meet the requirements of the Expect request-header field.^[21]

418 I’m a teapot (RFC 2324, RFC 7168)

This code was defined in 1998 as one of the traditional IETF April Fools’ jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. The RFC specifies this code should be returned by teapots requested to brew coffee.^[22] This HTTP status is used as an Easter egg in some websites, such as Google.com’s «I’m a teapot» easter egg.^[23][24][25] Sometimes, this status code is also used as a response to a blocked request, instead of the more appropriate 403 Forbidden.^[26][27]

421 Misdirected Request

The request was directed at a server that is not able to produce a response (for example because of connection reuse).

422 Unprocessable Entity

The request was well-formed but was unable to be followed due to semantic errors.^[8]

423 Locked (WebDAV; RFC 4918)

The resource that is being accessed is locked.^[8]

424 Failed Dependency (WebDAV; RFC 4918)

The request failed because it depended on another request and that request failed (e.g., a PROPPATCH).^[8]

425 Too Early (RFC 8470)

Indicates that the server is unwilling to risk processing a request that might be replayed.

426 Upgrade Required

The client should switch to a different protocol such as TLS/1.3, given in the Upgrade header field.

428 Precondition Required (RFC 6585)

The origin server requires the request to be conditional. Intended to prevent the ‘lost update’ problem, where a client GETs a resource’s state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.^[28]

429 Too Many Requests (RFC 6585)

The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.^[28]

431 Request Header Fields Too Large (RFC 6585)

The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large.^[28]

451 Unavailable For Legal Reasons (RFC 7725)

A server operator has received a legal demand to deny access to a resource or to a set of resources that includes the requested resource.^[29] The code 451 was chosen as a reference to the novel Fahrenheit 451 (see the Acknowledgements in the RFC).

5xx server errors

The server failed to fulfil a request.

Response status codes beginning with the digit «5» indicate cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and indicate whether it is a temporary or permanent condition. Likewise, user agents should display any included entity to the user. These response codes are applicable to any request method.

500 Internal Server Error

A generic error message, given when an unexpected condition was encountered and no more specific message is suitable.

501 Not Implemented

The server either does not recognize the request method, or it lacks the ability to fulfil the request. Usually this implies future availability (e.g., a new feature of a web-service API).

502 Bad Gateway

The server was acting as a gateway or proxy and received an invalid response from the upstream server.

503 Service Unavailable

The server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state.^[30]

504 Gateway Timeout

The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.

505 HTTP Version Not Supported

The server does not support the HTTP version used in the request.

506 Variant Also Negotiates (RFC 2295)

Transparent content negotiation for the request results in a circular reference.^[31]

507 Insufficient Storage (WebDAV; RFC 4918)

The server is unable to store the representation needed to complete the request.^[8]

508 Loop Detected (WebDAV; RFC 5842)

The server detected an infinite loop while processing the request (sent instead of 208 Already Reported).

510 Not Extended (RFC 2774)

Further extensions to the request are required for the server to fulfill it.^[32]

511 Network Authentication Required (RFC 6585)

The client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g., «captive portals» used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot).^[28]

Unofficial codes

The following codes are not specified by any standard.

419 Page Expired (Laravel Framework)

Used by the Laravel Framework when a CSRF Token is missing or expired.

420 Method Failure (Spring Framework)

A deprecated response used by the Spring Framework when a method has failed.^[33]

420 Enhance Your Calm (Twitter)

Returned by version 1 of the Twitter Search and Trends API when the client is being rate limited; versions 1.1 and later use the 429 Too Many Requests response code instead.^[34] The phrase «Enhance your calm» comes from the 1993 movie Demolition Man, and its association with this number is likely a reference to cannabis.^{[citation needed]}

430 Request Header Fields Too Large (Shopify)

Used by Shopify, instead of the 429 Too Many Requests response code, when too many URLs are requested within a certain time frame.^[35]

450 Blocked by Windows Parental Controls (Microsoft)

The Microsoft extension code indicated when Windows Parental Controls are turned on and are blocking access to the requested webpage.^[36]

498 Invalid Token (Esri)

Returned by ArcGIS for Server. Code 498 indicates an expired or otherwise invalid token.^[37]

499 Token Required (Esri)

Returned by ArcGIS for Server. Code 499 indicates that a token is required but was not submitted.^[37]

509 Bandwidth Limit Exceeded (Apache Web Server/cPanel)

The server has exceeded the bandwidth specified by the server administrator; this is often used by shared hosting providers to limit the bandwidth of customers.^[38]

529 Site is overloaded

Used by Qualys in the SSLLabs server testing API to signal that the site can’t process the request.^[39]

530 Site is frozen

Used by the Pantheon Systems web platform to indicate a site that has been frozen due to inactivity.^[40]

598 (Informal convention) Network read timeout error

Used by some HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.^[41]

599 Network Connect Timeout Error

An error used by some HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.

Internet Information Services

Microsoft’s Internet Information Services (IIS) web server expands the 4xx error space to signal errors with the client’s request.

440 Login Time-out

The client’s session has expired and must log in again.^[42]

449 Retry With

The server cannot honour the request because the user has not provided the required information.^[43]

451 Redirect

Used in Exchange ActiveSync when either a more efficient server is available or the server cannot access the users’ mailbox.^[44] The client is expected to re-run the HTTP AutoDiscover operation to find a more appropriate server.^[45]

IIS sometimes uses additional decimal sub-codes for more specific information,^[46] however these sub-codes only appear in the response payload and in documentation, not in the place of an actual HTTP status code.

nginx

The nginx web server software expands the 4xx error space to signal issues with the client’s request.^[47][48]

444 No Response

Used internally^[49] to instruct the server to return no information to the client and close the connection immediately.

494 Request header too large

Client sent too large request or too long header line.

495 SSL Certificate Error

An expansion of the 400 Bad Request response code, used when the client has provided an invalid client certificate.

496 SSL Certificate Required

An expansion of the 400 Bad Request response code, used when a client certificate is required but not provided.

497 HTTP Request Sent to HTTPS Port

An expansion of the 400 Bad Request response code, used when the client has made a HTTP request to a port listening for HTTPS requests.

499 Client Closed Request

Used when the client has closed the request before the server could send a response.

Cloudflare

Cloudflare’s reverse proxy service expands the 5xx series of errors space to signal issues with the origin server.^[50]

520 Web Server Returned an Unknown Error

The origin server returned an empty, unknown, or unexpected response to Cloudflare.^[51]

521 Web Server Is Down

The origin server refused connections from Cloudflare. Security solutions at the origin may be blocking legitimate connections from certain Cloudflare IP addresses.

522 Connection Timed Out

Cloudflare timed out contacting the origin server.

523 Origin Is Unreachable

Cloudflare could not reach the origin server; for example, if the DNS records for the origin server are incorrect or missing.

524 A Timeout Occurred

Cloudflare was able to complete a TCP connection to the origin server, but did not receive a timely HTTP response.

525 SSL Handshake Failed

Cloudflare could not negotiate a SSL/TLS handshake with the origin server.

526 Invalid SSL Certificate

Cloudflare could not validate the SSL certificate on the origin web server. Also used by Cloud Foundry’s gorouter.

527 Railgun Error

Error 527 indicates an interrupted connection between Cloudflare and the origin server’s Railgun server.^[52]

530

Error 530 is returned along with a 1xxx error.^[53]

AWS Elastic Load Balancer

Amazon’s Elastic Load Balancing adds a few custom return codes

460

Client closed the connection with the load balancer before the idle timeout period elapsed. Typically when client timeout is sooner than the Elastic Load Balancer’s timeout.^[54]

463

The load balancer received an X-Forwarded-For request header with more than 30 IP addresses.^[54]

561 Unauthorized

An error around authentication returned by a server registered with a load balancer. You configured a listener rule to authenticate users, but the identity provider (IdP) returned an error code when authenticating the user.^[55]

Caching warning codes (obsoleted)

The following caching related warning codes were specified under RFC 7234. Unlike the other status codes above, these were not sent as the response status in the HTTP protocol, but as part of the «Warning» HTTP header.^[56][57]

Since this «Warning» header is often neither sent by servers nor acknowledged by clients, this header and its codes were obsoleted by the HTTP Working Group in 2022 with RFC 9111.^[58]

110 Response is Stale

The response provided by a cache is stale (the content’s age exceeds a maximum age set by a Cache-Control header or heuristically chosen lifetime).

111 Revalidation Failed

The cache was unable to validate the response, due to an inability to reach the origin server.

112 Disconnected Operation

The cache is intentionally disconnected from the rest of the network.

113 Heuristic Expiration

The cache heuristically chose a freshness lifetime greater than 24 hours and the response’s age is greater than 24 hours.

199 Miscellaneous Warning

Arbitrary, non-specific warning. The warning text may be logged or presented to the user.

214 Transformation Applied

Added by a proxy if it applies any transformation to the representation, such as changing the content encoding, media type or the like.

299 Miscellaneous Persistent Warning

Same as 199, but indicating a persistent warning.

See also

• Custom error pages
• List of FTP server return codes
• List of HTTP header fields
• List of SMTP server return codes
• Common Log Format

Explanatory notes

References

External links

• «RFC 9110: HTTP Semantics and Content, Section 15 «Status Codes»«.
• Hypertext Transfer Protocol (HTTP) Status Code Registry

Если вы управляете веб-сайтами, понимание переадресации HTTP необходимо для надежной работы сайта. В этой статье мы подробно рассмотрим коды состояния HTTP 3xx, чтобы вы могли понять, как они работают, как лучше всего ими управлять и как они влияют на SEO.

Цель переадресации HTTP

При перенаправлении URL-адреса один адрес веб-страницы сопоставляется с другим. Существует ряд причин, по которым для вашего сайта требуется перенаправление.

Например, переход на новый домен является одной из основных причин использования перенаправления URL-адресов. Иногда ваше прежнее доменное имя слишком длинное и сложное для запоминания, или некоторые виды действий, нарушающих авторские права, вынуждают вас переходить с одного домена на другой.

Давайте подробнее рассмотрим другие причины перенаправления вашей страницы:

• Перенаправление нескольких доменов : постоянные HTTP-перенаправления необходимы для того, чтобы вести интернет-пользователей и поисковые системы в одно и то же место, имея при этом сразу несколько доменных имен.
• Выявление неработающих ссылок : 404 ненайденные страницы могут быть идентифицированы с помощью Google Search Console. Отчет о покрытии предоставит вам подробную информацию обо всех входящих ссылках на сайте, которые необходимо исправить с помощью перенаправления.
• Исправление неработающих URL-адресов : после определения неработающей ссылки вы можете перенаправить трафик на главную страницу. Однако лучшим вариантом является перенаправление каждого неработающего URL-адреса на новую страницу с таким же (аналогичным) содержанием.
• Новое местоположение страницы : если на вашем бывшем веб-сайте есть часто посещаемые страницы, которые имеют высокий рейтинг в поисковой выдаче, перенаправление поможет вам сопоставить этот URL-адрес с новым местоположением. В этом случае вы должны быть уверены, что старые страницы, которые вы использовали для перенаправления, не исчезли.
• Необходимость удаления страницы : создайте переадресацию HTTP для всех страниц, которые нужно удалить, и не пугайтесь и не пугайте посетителей ошибками 404 not found. Перенаправление будет сигнализировать Google или другим поисковым системам, что значение ссылки старых ссылок должно быть присвоено перенаправленным URL-адресам.

Помимо основных причин, перечисленных выше, есть и другие случаи, которые следует учитывать. Перенаправление пригодится, если вам нужно упростить и отслеживать медийную рекламу или справиться с чрезвычайными ситуациями. Редиректы помогают маркетологам отслеживать отклики на рекламу. В то же время веб-администраторы могут исправить любую неудачную операцию связывания (уведомления об ошибках, почтовые цепочки) с помощью перенаправления.

Подводя итог, Google определяет перенаправление для управления сканированием и индексированием (категория расширенной документации по SEO). Центр поиска Google объясняет переадресацию HTTP как практику выполнения плавного перехода, доступа к странице через несколько URL-адресов, исправления устаревших URL-адресов и отправки пользователей с удаленных страниц на новые, тем самым исключая 404 не найденные ошибки.

Основы веб-протокола

Основной протокол в Интернете, который используется для передачи данных и управления информацией на серверах хостинга, называется HTTP. Протокол передачи гипертекста позволяет поддерживать веб-сайты и обеспечивать связь между пользователями Интернета и серверами во всемирной паутине.

HTTP — это протокол, используемый для информационных систем с различными типами данных: распределенными, гипермедийными и совместными. Основная цель протокола передачи гипертекста — обеспечить беспрепятственное взаимодействие через Интернет. HTTP определяет модификации, а передача данных обеспечивает действия веб-сервера и браузера.

Этот протокол запрос-ответ работает через TCP-соединения, которые используются для связи с сервером. Протокол управления передачей позволяет интернет-поисковикам взаимодействовать с любыми доступными идентифицированными ресурсами, представленными во всемирной паутине. Связь пользователя с веб-серверами, серверами видео и сообщений осуществляется через HTTP. Таким образом клиенты могут получить доступ к веб-страницам.

Стоит отметить, что протокол передачи гипертекста использует прокси. Это специализированные фильтры для идентификации и анализа контента. Прокси-серверы HTTP не позволяют пользователям отправлять и отображать файлы низкого качества:

• текст и изображения шпионского ПО
• искаженные мультимедийные файлы
• звуковые и видеофайлы, связанные с кибератаками

Есть режимы работы HTTP прокси. HTTP-клиент используется для защиты браузера пользователя. Он отправляет сообщения запроса на сервер. HTTP-сервер отвечает за HTTP-ответные соединения. Принцип работы HTTP-прокси можно представить следующим образом:

Основные преимущества протоколов HTTP:

• Ответственность за запрос : расширенная схема адресации обеспечивается протоколами HTTP. Все IP-адреса становятся легко узнаваемыми и идентифицируемыми в WWW.
• Улучшено взаимодействие с веб-ресурсами : достигается гибкость и доступность онлайн-ресурсов. HTTP предоставляет возможность загрузки расширений и плагинов. Таким образом отображаются соответствующие данные.

Согласно Hitech Whiz, есть и другие преимущества протокола передачи гипертекста, которые следует учитывать:

• Безопасность : перехват сведен к минимуму, поэтому передача данных происходит в безопасном для пользователей режиме.
• Кеширование страницы : если пользователь ранее заходил на интернет-ресурс, доступный на странице контент будет загружаться быстрее.
• Сниженная задержка : HTTP инициирует процесс установления связи сразу после установления соединения. Эта опция уменьшает задержку, связанную с подключением.

HTTP также известен своими методами, зависящими от веб-протокола. Они меняются от одной задачи к другой. Существует девять методов запроса для выполнения различных веб-операций.

Запрос, зависящий от протокола	Описание
PUT	Отвечает за доработку существующего веб-ресурса. Этот запрос также позволяет создать новый URL.
HEAD	Создает запрос для ресурса специального назначения без необходимости в основном содержимом.
POST	Отвечает за изменения существующих ресурсов при добавлении контента на новую веб-страницу.
DELETE	Удаляет ресурс, указанный веб-мастером.
GET	Запрашивает ресурс о его целостности.
TRACE	Отображает любые обновления и изменения веб-ресурса, посещенного пользователем.
OPTIONS	Демонстрирует список HTTP-методов, доступных для интересующего пользователя URL-адреса.
CONNECT	Отвечает за преобразование соединения на основе запроса в туннель TCP / IP.
PATCH	Позволяет проводить частичные модификации веб-ресурса.

Что такое коды состояния ответа HTTP?

Коды состояния HTTP — это специальные элементы, которые определяют ответ сервера и представлены в виде трех жестких когерентных символов. Каждый код протокола передачи гипертекста используется для ошибок REST API. Для выявления проблем и их решения необходимо понимать каждый код статуса HTTP.

Необходимо учитывать пять классов кодов состояния. Есть информационный ответ, успешный ответ, перенаправление, ошибка клиента и категории ошибок обслуживания. Первый жесткий указывает на класс кода состояния HTTP. Давайте подробнее рассмотрим каждую категорию ответов:

• Информационный ответ 1xx : этот класс кодов состояния информирует о приеме запроса. Значит, процесс продолжается. Например, 100 = продолжить.
• 2xx успешно : группа этих кодов состояния относится к пониманию и принятию запроса. Например, 200 = ОК.
• Перенаправление 3xx : этот класс кодов состояния HTTP указывает, что для выполнения запроса требуются некоторые специальные действия. Например, 301 = перенаправление.
• Ошибка клиента 4xx : эта категория кодов состояния ответа указывает на то, что запрос не может быть выполнен. Кроме того, это может означать, что в запросе неверный синтаксис. 400 = неверный запрос.
• Ошибка сервера 5xx : этот класс кодов состояния HTTP связан с неудачным ответом сервера, вызванным неудачной обработкой сервера. Например, 500 = внутренняя ошибка.

Стоит отметить, что некоторые коды состояния и ошибки напрямую влияют на SEO. В то время как классы 1xx и 2xx не сильно влияют на поисковую оптимизацию (хотя лучше всего использовать ответ 200), классы 300, 400 и 500 могут негативно повлиять на сканирование и индексирование ваших веб-страниц. Вы всегда должны следить за кодами состояния и ошибками 4xx и 5xx, так как это может быть очень вредным для рейтинга вашего сайта в целом.

Коды HTTP 300, возможно, играют центральную роль для SEO. Этот класс кодов статуса отвечает за передачу всего SEO-значения от ваших старых URL-адресов к новым. Таким образом, необходимо вникнуть в значение каждого 300-уровневого кода (временные или постоянные перенаправления, прокси, множественный выбор и т. Д.).

Полный список кодов состояния HTTP 3xx

Коды состояния HTTP предназначены для перенаправления URL-адресов. Коды уровня 300 обозначают различные типы перенаправлений HTTP. Маркетологи обычно используют коды состояния 3xx для отслеживания и анализа пользовательского опыта, поведения пользователей веб-сайта и эффективности SEO. В DataTracker ресурсы определяют четыре типа переадресаций распределенных по кодам состояния HTTP 300 уровня:

• Такие перенаправления, как 301, 302, 307, указывают на то, что целевому ресурсу был назначен новый URL.
• Перенаправление 300 предлагает несколько вариантов (выбор подходящих веб-ресурсов в соответствии с запросом).
• 303 перенаправление предлагает косвенный ответ на выполненный запрос, если поле Location идентифицирует его.
• Перенаправление 304 обеспечивает перенаправление HTTP на результаты, которые были предварительно кэшированы.

Коды состояния 300 уровня появляются, когда необходимо указать ответ перенаправления от сервера. Другой пример действия класса кода состояния HTTP 3xx — это когда удаленная страница сохраняет свой рейтинг. Кроме того, редиректы пригодятся, когда необходимо исправить неработающий URL.

Например, перенаправление 301 было использовано через PHP для перемещения всего трафика на новую страницу https://eurovps.com:

<?php // Permanent 301 Redirect via PHP

header("HTTP1.1 301 Moved Permanently");

header("Location: https://eurovps.com/");

Таким образом, он сохраняет рейтинг прежнего URL-адреса. Тот же алгоритм можно использовать для исправления неработающих URL-адресов с помощью постоянного редиректа.

Перенаправления не ожидают появления ошибок, связанных с другими кодами ответа. Например, перенаправления не решают проблемы с информационными ответами или ошибками сервера / клиента ( Не реализовано = 501; Плохой шлюз = 502; Непроцессированная сущность = 420).

Давайте подробнее рассмотрим каждый 300-уровневый код, чтобы понять их влияние на SEO и рейтинг веб-сайта. Вам необходимо просмотреть девять кодов состояния 3xx, а также их особенности, функции, преимущества и различия.

300 Multiple Choices

Эти коды состояния обычно используются в REST API. Браузеру предоставляется несколько вариантов выбора, который должен выбрать сторону ресурсов, отвечающих запросу. Например, если вам нужно указать несколько опций формата видео или разных расширений файлов, вам пригодится 300-уровневый код.

Еще одна причина для использования 300 редиректов — это соответствие требованиям агентских переговоров. Сервер информирует пользовательский агент о доступных типах представлений на выбор. Присмотритесь к примеру, чтобы увидеть 300-редирект в действии:

HTTP/1.1 300 Multiple Choices
Server: curveball/0.3.1
Access-Control-Allow-Headers: Content-Type,User-Agent
Access-Control-Allow-Origin: *
Link: </foo> rel="alternate"
Link: </bar> rel="alternate"
Content-Type: text/html
Location: /foo

Вы можете увидеть /fooи /barв кодировке. Местоположение указывается, когда доступны для выбора оба варианта.

301 Moved Permanently

Еще один код состояния обычно используется в REST API. Основная идея — перенаправление постоянное. Если вам нужно использовать перенаправление на короткое время, редирект 301 не подходит для этой цели. И пользователи Интернета, и поисковые системы переходят на новый URL-адрес с помощью кода состояния 301 HTTP. Наилучший сценарий перенаправления этого типа — когда восстановление прежней страницы не планируется.

Давайте объясним концепцию постоянных перенаправлений HTTP на примере реального случая:

• Страница часто задаваемых вопросов размещена на субдомене ( https://faq.website.com).
• Вы решили переместить свою страницу часто задаваемых вопросов в подпапку ( https://www.website.com/faq/).
• Если поддомен удалить, появится страница 404, которая нанесет вред вашему SEO.
• Пользовательский интерфейс также страдает от этой практики, поэтому перенаправление является обязательным.
• Разместите 301 редирект, чтобы пользователи не могли посещать ваш старый URL.
• Поисковые системы также будут перенаправлены на новую страницу часто задаваемых вопросов.

Рассмотрим еще один пример постоянного перенаправления (301 редирект). Здесь мы видим код состояния 301 HTTP, используемый для перенаправления пользователей и поисковых систем в новое место. Выделенные изменения выделены жирным желтым цветом.

Программисты часто используют.htaccessфайл для реализации различных типов перенаправления, включая перенаправление 301. Следует учитывать два метода переадресации 301:

• Весь домен может быть перенаправлен на новый веб-сайт. Добавьте после Redirect 301интересующего вас домена:

Redirect 301 /[http://www.website.com/](http://www.website.com/)

• Если вы хотите перенаправить только одну страницу, необходимо указать старый URL после Redirect 301:

Redirect 301 /oldurl/ [http://www.website.com/newurl/](http://www.website.com/newurl/)

Здесь важно упомянуть, что для различных подходов к кодированию требуются разные реализации перенаправления. Например, реализация 301 редиректа с использованием PHP будет выглядеть так:

<?php
header("Location: https://www.website.com/", true, 301);
exit();
?>

Обратите внимание, что JavaScript далеко не оптимален для SEO. Иногда Google неправильно интерпретирует 301 редирект в JavaScript. Если вас интересует постоянное перенаправление, оптимизированное для SEO, лучше выбрать один из перечисленных выше методов.

302 Found

В REST API есть еще один часто используемый код состояния. По сравнению с постоянными перенаправлениями 301, используются 302-уровневые, когда требуются некоторые временные перенаправления. Например, вы знаете об изменениях в этом URL-адресе, который вы скоро перенаправите, или прежняя страница будет восстановлена ​​в какой-то момент. Еще один случай, когда вы должны удалить старую страницу, но вам нужно перенаправить весь трафик и сохранить оценки рейтинга на временном URL-адресе. Среди других причин использования кода состояния 302:

• Миграция на новый, но временный домен
• Изменение структуры сайта (но временно).

Стоит отметить, что реализация 302 редиректа может осуществляться так же, как и для 301-го уровня. Здесь также применима рекомендация избегать кодирования JavaScript в целях оптимизации SEO.

Например, на изображении выше мы можем увидеть, как код состояния 302 уровня используется для временного перемещения веб-сайта. Обратите внимание, что вы также можете использовать этот тип перенаправления для редизайна вашего веб-сайта / страницы, некоторого тестирования, проведения рекламных акций и других краткосрочных мероприятий и договоренностей.

303 See Other

Этот код состояния HTTP позволяет REST API отправлять клиентам предложения в форме ссылок. Примечательной особенностью переадресации 303 является их производительность без кеширования. Но стоит отметить, что второй сеанс перенаправления будет кеширован.

Код статуса 303 не имеет значения для SEO. Тем не менее, это может помочь повысить удобство использования и реализовать маркетинговые цели, когда можно предложить другой URL-адрес вместо уже посещенного.

303 See Other

Этот код обычно используется в REST API, как и другие перечисленные выше 3xx. Если повторная передача не требуется, можно использовать неизмененный код состояния. Если страница еще не была изменена, можно сделать переадресацию без кеша.

Давайте подробнее рассмотрим кодирование на примере перенаправления 304. Код состояния указывается в запрошенном методе и URL-адресе.

305 Use Proxy

Этот код состояния HTTP пока не рекомендуется. Некоторые браузеры не позволяют использовать этот тип перенаправления. Например, Mozilla Firefox и Internet Explorer запрещают пользователям выполнять переадресацию 305 по соображениям безопасности. Основное объяснение этой ситуации — единственный прокси-сервер, используемый для обработки запроса и предоставления доступа к веб-ресурсу. Этот подход опасен для некоторых браузеров.

306 Switch Proxy (Unused)

Программисты сейчас не используют этот статусный код. Его основная идея заключалась в возможности переключать прокси при выполнении какого-либо специального запроса. Пользователь вернется к указанному прокси по умолчанию, если этот тип перенаправления будет представлен в кодировке.

307 Temporary Redirect

Этот код состояния HTTP очень похож на код состояния 302. Вот почему метод реализации, необходимый для перенаправления, такой же, как для 301 и 302. Давайте углубимся в разницу между 207 и 302, поскольку оба они относятся к временным перенаправлениям HTTP. Специалисты до сих пор дискутируют на эту тему. Для наших целей есть два мнения о 307 редиректах:

• 307 и 302 редиректы обеспечивают одинаковое временное перемещение контента. При некоторых быстрых изменениях рекомендуется использовать один из этих кодов состояния.
• Есть разница между временными перенаправлениями 302 и 307. Код состояния 302 уровня примечателен изменением метода HTTP. При этом используется 307 редиректов без изменения метода HTTP.

Это означает, что любые изменения метода запроса GET в 302 редиректах приводят к непредсказуемым результатам в сети. Этого не происходит с 307 редиректами. На рисунке ниже показан пример использования временного перенаправления на уровне 307.

308 Permanent Redirect

Этот код состояния считается экспериментальным, но имеет ту же семантику, что и постоянное перенаправление 301. Единственная разница между перенаправлениями 308 и 301 — это доступность изменений метода HTTP. В то время как перенаправления 301 позволяют пользовательским агентам изменять используемые методы HTTP, код состояния 308 подразумевает неизменяемые методы HTTP-запроса для перенаправления.

Код состояния 308 HTTP довольно новый, так как он был введен только в 2015 году. Некоторые браузеры до сих пор не могут распознавать 308 редиректы и показывать пользователям пустые страницы вместо перенаправленных (например, Internet Explorer 11). Вот почему 301 постоянная переадресация будет предпочтительнее из-за лучшей поддержки и удобства для SEO. Код состояния HTTP уровня 308 по-прежнему плохо поддерживается, и поисковые роботы не всегда его распознают.

Значение кода состояния HTTP 3xx для SEO

300-уровневая переадресация важна для сохранения ценности SEO. Если вам нужно перейти с одной старой страницы на другую и вы не хотите терять ее рейтинг, рекомендуется временное или постоянное перенаправление. Чтобы сохранить ссылочный вес и не навредить SEO вашего сайта, когда дело доходит до редизайна или других изменений, вы можете использовать несколько кодов HTTP 300:

• 301 или 308 для постоянной переадресации
• 302, 303, 307 для временных перенаправлений

Перенаправления не вредят поисковой оптимизации, но помогают избежать потери авторитета. Необходимо правильно перенаправлять страницы, чтобы сохранить рейтинг Google и ссылочный вес.

Когда использовать 301 или 302 редирект для SEO

Когда дело доходит до временных и постоянных перенаправлений, коды состояния HTTP 301 и 302 всегда имеют приоритет. Но есть разница между этими кодами HTTP 300. Вот первый сценарий. Вы решили навсегда удалить свой старый сайт. Но этот URL-адрес часто посещался и был высоко оценен поисковыми системами. Есть рекомендация использовать постоянное перенаправление 301, чтобы поддерживать ссылочный вес и рейтинг Google.

Второй сценарий — это когда вы реструктурируете свой веб-сайт и сохраняете результаты поиска в течение некоторого краткосрочного периода. Сайт потеряет SEO-ценность. Поисковые системы сохранят ваш старый URL, но начнут индексировать вашу новую страницу после перенаправления. Если вы уверены, что все обновления и редизайны подойдут к концу и вы вернетесь к старому URL-адресу, лучше использовать 302 редиректа (временный).

Если вы неправильно используете коды HTTP 300, эти ошибки могут повлиять на вашу поисковую оптимизацию. Вот краткий список случаев, когда стратегии SEO терпят неудачу из-за неправильных перенаправлений:

• Вы использовали 301 редирект для временных изменений сайта. В результате Google может исключить ваши старые URL-адреса, необходимые для SEO, из индексации поисковой системой. Вы полностью потеряете ссылочный вес и рейтинг.
• Вы использовали переадресацию 302 для страницы, которая будет удалена навсегда. Поисковые системы продолжают обращать внимание на вашу старую страницу, потому что понимают, что все ваши изменения временные. Таким образом, вы теряете SEO-ценность ваших новых URL-адресов.

Обратите внимание, что код состояния 301 подходит для тематических кластеров. Если вам действительно нужны постоянные перенаправления, не используйте 302. Предотвратите риск потери рейтинга и трафика. Перенаправления 302 заставляют поисковые системы продолжать индексировать ваши старые страницы и не позволяют им передавать ссылочный вес вашим новым. Убедитесь, что вы всегда проверяете точность кода состояния HTTP на своем веб-сайте с помощью специального программного обеспечения, такого как WTOOLS и Redirect Checker.

301 и 302

Параметры для сравнения	301	302
Тип перенаправления	Постоянный	Временный
Когда это используется?	Для перенаправления старых страниц, которые собираются удалить.	Для перенаправления старых страниц, которые будут восстановлены.
SEO ценность	Сохраняет рейтинг старых страниц вместе с их ссылочным весом и передает их на целевой URL.	Позволяет пользователям сохранять рейтинг старых страниц вместе с их ссылочным весом и временно переносить их все на целевой URL.
Сигнал канонизации	Более сильный сигнал канонизации для Google	Средний сигнал канонизации для поисковых систем
Синтаксис перенаправлений	Изменено	Изменено

Постоянные перенаправления

Параметры для сравнения	301	308
Тип перенаправления	Постоянный	Постоянный
Когда это используется?	Для перенаправления старых страниц, которые собираются удалить.	Для перенаправления старых страниц, которые будут удалены.
Специальные	Предпочтительно для SEO; хорошо распознается краулерами; для постоянных редиректов; полное количество ссылок на перенаправленную страницу.	Экспериментальный; ограничена в поддержке; во избежание некорректных изменений метода GET.
SEO ценность	Сохраняет рейтинг старых страниц вместе с их ссылочным весом и передает их на целевой URL.	Сохраняет рейтинг старых страниц вместе с их ссылочным весом и передает их на целевой URL.
Сигнал канонизации	Более сильный сигнал канонизации для Google	Снижение сигнала канонизации для поисковых систем
Синтаксис перенаправлений	Изменено	Не изменено

301 имеет более сильную канонизацию для Google. В то же время представитель команды Google Джон Мюллер заявил, что коды состояния HTTP 308 и 301 обеспечивают одинаковые свойства перенаправления и SEO.

Временные перенаправления

Параметры для сравнения	302	307
Тип перенаправления	Временный	Временный
Когда это используется?	Для перенаправления старых страниц, которые планируется восстановить.	Для перенаправления старых страниц, которые будут восстановлены.
Специальные	Для временных перенаправлений; хорошо распознается поисковыми роботами.	Предпочтительно для SEO; во избежание некорректных изменений метода GET; переносит запросы клиентов на другой хост.
SEO ценность	Позволяет пользователям сохранять рейтинг старых страниц вместе с их ссылочным весом и временно переносить их на целевой URL.	Позволяет пользователям сохранять рейтинг старых страниц вместе с их ссылочным весом и временно переносить их на целевой URL.
Сигнал канонизации	Сильный сигнал канонизации для Google	Сильный сигнал канонизации для поисковых систем
Синтаксис перенаправлений	Изменено	Не изменено

Код статуса 307 предпочтительнее для специалистов по SEO. Из-за изменения синтаксиса 302 перенаправлений это может вызвать любое неожиданное поведение. Кроме того, в этом руководстве Rest API указано, что 307 редиректов пригодятся при переносе клиентских запросов на другой хост.

MOZ предлагает 302 редиректа, если по существу невозможно определить, идентифицировали ли поисковые системы страницу как совместимую. Таким образом, любой контент, который временно перемещается на другую страницу, должен быть перенаправлен с помощью кода состояния 302 HTTP. Сканеры отметят изменения, и URL-адрес будет правильно проиндексирован.

Проверка кодов состояния HTTP в рейтинге SE

Чтобы отслеживать, как Google воспринимает коды состояния HTTP на вашем веб-сайте, вам необходимо провести аудит веб-сайта. Существует ряд специализированных инструментов для проведения аналитических исследований на местах. Рассмотрим подробнее особенности процесса аналитического исследования на примере программы SEO-аудита сайтов.

SE Ranking предлагает отчет об аудите сайта с описанием проблем и руководством по исправлению для глубокого анализа всех критических технических показателей веб-сайта, включая сканирование, безопасность, удобство использования, ошибки скорости и другие. Программа детально анализирует каждую страницу веб-сайта, включая ошибки перенаправления и протокола передачи гипертекста. Вот алгоритм, чтобы получить представление о кодах статуса HTTP вашего сайта:

1. Откройте раздел Аудит сайта.
2. Укажите веб-сайт, на котором будет запущена проверка.
3. Один из отчетов будет содержать коды состояния HTTP.

Инфографика будет содержать доминирующий класс кода состояния HTTP (1xx, 2xx, 3xx, 4xx, 5xx). Дополнительно в отчете (под основной инфографикой) будет указано количество перенаправлений и отсоединенных страниц.

Во время полного аудита веб-сайта SE Ranking обнаруживает слабые места и ошибки, связанные с кодами состояния HTTP, предоставляет описания проблем и предлагает способы их устранения для повышения производительности вашего веб-сайта в Интернете.

Какие коды 3xx вам действительно нужно знать

Все коды HTTP 300 заслуживают внимания современных представителей бизнеса, которые заинтересованы в хорошей видимости в Интернете. Например, 300 (множественный выбор) будет полезен для выполнения некоторых маркетинговых стратегий, когда пользователь должен выбирать между несколькими объектами одновременно. Код состояния 303 (см. Прочее) пригодится, когда другой URL-адрес должен использоваться для перенаправления на интересующий ресурс.

Но основные коды HTTP 300 — это 301, 302 и 307, потому что они используются для временных и постоянных перенаправлений. Эти коды состояния рекомендуются для обеспечения миграции веб-сайтов с оптимизацией поисковых систем, изменения URL-адресов, реструктуризации и обновлений сайта, смены доменов или коротких повторных публикаций для страниц веб-сайтов.

Стоит отметить, что к процессу перенаправления предъявляются некоторые требования, чтобы соответствовать стандартам рейтинга Google и не терять ссылочный вес. Следует помнить пять основных советов:

• Переходите на новый домен только после 301 редиректа. Google не любит дублированный контент и может наказать вас за эту ошибку.
• Установите 301, 302 и 307 редирект между версиями http://и http://wwwвашего домена. Это очень важно для вашей поисковой оптимизации.
• Обратите внимание на предпочтения Google в отношении цепочек переадресации. Не превышайте двух переадресаций подряд. В случае чрезмерного использования переадресации сканеры перестанут посещать ваш сайт.
• Используйте полезные инструменты, такие как Google Search Console, HTTP Status, WTOOLS HTTP Checker, Redirect Checker или инструмент аудита веб-сайтов для ранжирования SE, чтобы упростить мониторинг кода состояния HTTP и своевременное внесение изменений.
• Перепланируйте свою стратегию SEO, если вы собираетесь перейти с одного веб-сайта на другой. Рассмотрите поиск по ключевым словам, новые стратегии контент-маркетинга и другие фундаментальные приготовления.