Как исправить ошибку 499

В конце прошлой недели я заметил проблему на одном из моих средних экземпляров AWS, где Nginx всегда возвращает ответ HTTP 499, если запрос занимает более 60 секунд. Запрошенная страница представляет собой скрипт PHP

Я провел несколько дней, пытаясь найти ответы, и попробовал все, что я могу найти в Интернете, включая несколько записей здесь, в Stack Overflow, ничего не работает.

• $ _SERVER не дает значения
• Nginx переписать не работает с расширением .php
• Ошибка nginx подключиться к php5-fpm.sock не удалось (13: отказ от прав)
• php-fpm разбился, когда curl или file_get_contents запросили https-url
• Сложность Ioncube с PHP 5.5

Я пробовал изменять настройки PHP, настройки PHP-FPM и настройки Nginx. Вы можете увидеть вопрос, который я поднял на форумах NginX в пятницу ( http://forum.nginx.org/read.php?9,237692 ), хотя он не получил ответа, поэтому я надеюсь, что я смогу найти ответьте здесь, прежде чем я вынужден вернуться к Apache, который, как я знаю, работает.

Это не та же проблема, что и ошибки HTTP 500 в других записях.

Я смог реплицировать проблему с помощью нового экземпляра micro AWS NginX с использованием PHP 5.4.11.

Чтобы помочь любому, кто хочет увидеть проблему в действии, я собираюсь провести вас через настройку, которую я запускал для последнего тестового сервера Micro.

Вам нужно будет запустить новый экземпляр AWS Micro (поэтому он бесплатный) с помощью AMI ami-c1aaabb5

Эта запись PasteBin имеет полную настройку для запуска, чтобы отразить мою тестовую среду. Вам просто нужно изменить example.com в конфигурации NginX в конце

http://pastebin.com/WQX4AqEU

Как только вы настроитесь, вам просто нужно создать образец файла PHP, который я тестирую, с которым

<?php sleep(70); die( 'Hello World' ); ?> 

Сохраните это в webroot, а затем проверьте. Если вы запустите скрипт из командной строки, используя php или php-cgi, он будет работать. Если вы получите доступ к скрипту через веб-страницу и закроете журнал доступа /var/log/nginx/example.access.log , вы заметите, что получите ответ HTTP 1.1 499 через 60 секунд.

Теперь, когда вы можете увидеть таймаут, я рассмотрю некоторые изменения конфигурации, которые я сделал как для PHP, так и для NginX, чтобы попытаться обойти это. Для PHP я создам несколько файлов конфигурации, чтобы их можно было легко отключить

Обновите PHP FPM Config, чтобы включить внешние файлы конфигурации

 sudo echo ' include=/usr/local/php/php-fpm.d/*.conf ' >> /usr/local/php/etc/php-fpm.conf в sudo echo ' include=/usr/local/php/php-fpm.d/*.conf ' >> /usr/local/php/etc/php-fpm.conf 

Создайте новую конфигурацию PHP-FPM для переопределения таймаута запроса

 sudo echo '[www] request_terminate_timeout = 120s request_slowlog_timeout = 60s slowlog = /var/log/php-fpm-slow.log ' > /usr/local/php/php-fpm.d/timeouts.conf 

Измените некоторые глобальные настройки, чтобы обеспечить интервал аварийного перезапуска 2 минуты

 # Create a global tweaks sudo echo '[global] error_log = /var/log/php-fpm.log emergency_restart_threshold = 10 emergency_restart_interval = 2m process_control_timeout = 10s ' > /usr/local/php/php-fpm.d/global-tweaks.conf 

Затем мы изменим некоторые параметры PHP.INI, снова используя отдельные файлы

 # Log PHP Errors sudo echo '[PHP] log_errors = on error_log = /var/log/php.log ' > /usr/local/php/conf.d/errors.ini sudo echo '[PHP] post_max_size=32M upload_max_filesize=32M max_execution_time = 360 default_socket_timeout = 360 mysql.connect_timeout = 360 max_input_time = 360 ' > /usr/local/php/conf.d/filesize.ini 

Как вы можете видеть, это увеличивает тайм-аут сокета до 3 минут и помогает регистрировать ошибки.

Наконец, я отредактирую некоторые параметры NginX, чтобы увеличить тайм-аут той стороны

Сначала я редактирую файл /etc/nginx/nginx.conf и добавляю его в директиву http fastcgi_read_timeout 300;

Затем я редактирую файл / etc / nginx / sites-enabled / example, который мы создали ранее (см. Запись pastebin), и добавьте следующие параметры в директиву сервера

 client_max_body_size 200; client_header_timeout 360; client_body_timeout 360; fastcgi_read_timeout 360; keepalive_timeout 360; proxy_ignore_client_abort on; send_timeout 360; lingering_timeout 360; 

Наконец, я добавляю следующее в раздел ~ .php $ сервера dir

 fastcgi_read_timeout 360; fastcgi_send_timeout 360; fastcgi_connect_timeout 1200; 

Прежде чем повторять сценарий, запустите nginx и php-fpm, чтобы убедиться, что новые настройки были подняты. Затем я пытаюсь получить доступ к странице и все еще получаю запись HTTP / 1.1 499 в файле NginX example.error.log.

Итак, где я иду не так? Это просто работает на apache, когда я устанавливаю максимальное время выполнения PHP до 2 минут.

Я вижу, что настройки PHP были подобраны, запустив phpinfo () с веб-страницы. Я просто не понимаю, я действительно думаю, что слишком много было увеличено, так как это должно было просто потребовать изменения max_execution_time PHP, default_socket_timeout, а также fastcgi_read_timeout от NginX только в директиве location-> server .

Обновление 1

Проведя еще один тест, чтобы показать, что проблема заключается не в том, что клиент умирает, я модифицировал тестовый файл

 <?php file_put_contents('/www/log.log', 'My first data'); sleep(70); file_put_contents('/www/log.log','The sleep has passed'); die('Hello World after sleep'); ?> 

Если я запустил скрипт с веб-страницы, я увижу, что содержимое файла будет установлено в первую строку. Через 60 секунд в журнале NginX появляется ошибка. Через 10 секунд содержимое файла изменяется на вторую строку, доказывая, что PHP завершает процесс.

Обновление 2

Установка fastcgi_ignore_client_abort; изменяет ответ от HTTP 499 на HTTP 200, хотя ничего не возвращается конечному клиенту.

Обновление 3

Установив Apache и PHP (5.3.10) на поле прямо (используя apt), а затем увеличивая время выполнения, проблема также возникает и на Apache. Симптомы такие же, как и у NginX, ответ HTTP200, но фактическое время соединения с клиентом перед раздачей.

Я также начал замечать в журналах NginX, что если я тестирую с помощью Firefox, он делает двойной запрос (например, этот PHP-скрипт выполняется дважды, когда он длится более 60 секунд ). Хотя, похоже, это клиент, запрашивающий при неудачном сценарии

At the end of last week I noticed a problem on one of my medium AWS instances where Nginx always returns a HTTP 499 response if a request takes more than 60 seconds. The page being requested is a PHP script

I’ve spent several days trying to find answers and have tried everything that I can find on the internet including several entries here on Stack Overflow, nothing works.

I’ve tried modifying the PHP settings, PHP-FPM settings and Nginx settings. You can see a question I raised on the NginX forums on Friday (http://forum.nginx.org/read.php?9,237692) though that has received no response so I am hoping that I might be able to find an answer here before I am forced to moved back to Apache which I know just works.

This is not the same problem as the HTTP 500 errors reported in other entries.

I’ve been able to replicate the problem with a fresh micro AWS instance of NginX using PHP 5.4.11.

To help anyone who wishes to see the problem in action I’m going to take you through the set-up I ran for the latest Micro test server.

You’ll need to launch a new AWS Micro instance (so it’s free) using the AMI ami-c1aaabb5

This PasteBin entry has the complete set-up to run to mirror my test environment. You’ll just need to change example.com within the NginX config at the end

http://pastebin.com/WQX4AqEU

Once that’s set-up you just need to create the sample PHP file which I am testing with which is

<?php
sleep(70);
die( 'Hello World' );
?>

Save that into the webroot and then test. If you run the script from the command line using php or php-cgi, it will work. If you access the script via a webpage and tail the access log /var/log/nginx/example.access.log, you will notice that you receive the HTTP 1.1 499 response after 60 seconds.

Now that you can see the timeout, I’ll go through some of the config changes I’ve made to both PHP and NginX to try to get around this. For PHP I’ll create several config files so that they can be easily disabled

Update the PHP FPM Config to include external config files

sudo echo '
include=/usr/local/php/php-fpm.d/*.conf
' >> /usr/local/php/etc/php-fpm.conf

Create a new PHP-FPM config to override the request timeout

sudo echo '[www]
request_terminate_timeout = 120s
request_slowlog_timeout = 60s
slowlog = /var/log/php-fpm-slow.log ' >
/usr/local/php/php-fpm.d/timeouts.conf

Change some of the global settings to ensure the emergency restart interval is 2 minutes

# Create a global tweaks
sudo echo '[global]
error_log = /var/log/php-fpm.log
emergency_restart_threshold = 10
emergency_restart_interval = 2m
process_control_timeout = 10s
' > /usr/local/php/php-fpm.d/global-tweaks.conf

Next, we will change some of the PHP.INI settings, again using separate files

# Log PHP Errors
sudo echo '[PHP]
log_errors = on
error_log = /var/log/php.log
' > /usr/local/php/conf.d/errors.ini

sudo echo '[PHP]
post_max_size=32M
upload_max_filesize=32M
max_execution_time = 360
default_socket_timeout = 360
mysql.connect_timeout = 360
max_input_time = 360
' > /usr/local/php/conf.d/filesize.ini

As you can see, this is increasing the socket timeout to 3 minutes and will help log errors.

Finally, I’ll edit some of the NginX settings to increase the timeout’s that side

First I edit the file /etc/nginx/nginx.conf and add this to the http directive
fastcgi_read_timeout 300;

Next, I edit the file /etc/nginx/sites-enabled/example which we created earlier (See the pastebin entry) and add the following settings into the server directive

client_max_body_size    200;
client_header_timeout   360;
client_body_timeout     360;
fastcgi_read_timeout    360;
keepalive_timeout       360;
proxy_ignore_client_abort on;
send_timeout            360;
lingering_timeout       360;

Finally I add the following into the location ~ .php$ section of the server dir

fastcgi_read_timeout 360;
fastcgi_send_timeout 360;
fastcgi_connect_timeout 1200;

Before retrying the script, start both nginx and php-fpm to ensure that the new settings have been picked up. I then try accessing the page and still receive the HTTP/1.1 499 entry within the NginX example.error.log.

So, where am I going wrong? This just works on apache when I set PHP’s max execution time to 2 minutes.

I can see that the PHP settings have been picked up by running phpinfo() from a web-accessible page. I just don’t get, I actually think that too much has been increased as it should just need PHP’s max_execution_time, default_socket_timeout changed as well as NginX’s fastcgi_read_timeout within just the server->location directive.

Update 1

Having performed some further test to show that the problem is not that the client is dying I have modified the test file to be

<?php
file_put_contents('/www/log.log', 'My first data');
sleep(70);
file_put_contents('/www/log.log','The sleep has passed');
die('Hello World after sleep');
?>

If I run the script from a web page then I can see the content of the file be set to the first string. 60 seconds later the error appears in the NginX log. 10 seconds later the contents of the file changes to the 2nd string, proving that PHP is completing the process.

Update 2

Setting fastcgi_ignore_client_abort on; does change the response from a HTTP 499 to a HTTP 200 though nothing is still returned to the end client.

Update 3

Having installed Apache and PHP (5.3.10) onto the box straight (using apt) and then increasing the execution time the problem does appear to also happen on Apache as well. The symptoms are the same as NginX now, a HTTP200 response but the actual client connection times out before hand.

I’ve also started to notice, in the NginX logs, that if I test using Firefox, it makes a double request (like this PHP script executes twice when longer than 60 seconds). Though that does appear to be the client requesting upon the script failing

At the end of last week I noticed a problem on one of my medium AWS instances where Nginx always returns a HTTP 499 response if a request takes more than 60 seconds. The page being requested is a PHP script

I’ve spent several days trying to find answers and have tried everything that I can find on the internet including several entries here on Stack Overflow, nothing works.

I’ve tried modifying the PHP settings, PHP-FPM settings and Nginx settings. You can see a question I raised on the NginX forums on Friday (http://forum.nginx.org/read.php?9,237692) though that has received no response so I am hoping that I might be able to find an answer here before I am forced to moved back to Apache which I know just works.

This is not the same problem as the HTTP 500 errors reported in other entries.

I’ve been able to replicate the problem with a fresh micro AWS instance of NginX using PHP 5.4.11.

To help anyone who wishes to see the problem in action I’m going to take you through the set-up I ran for the latest Micro test server.

You’ll need to launch a new AWS Micro instance (so it’s free) using the AMI ami-c1aaabb5

This PasteBin entry has the complete set-up to run to mirror my test environment. You’ll just need to change example.com within the NginX config at the end

http://pastebin.com/WQX4AqEU

Once that’s set-up you just need to create the sample PHP file which I am testing with which is

<?php
sleep(70);
die( 'Hello World' );
?>

Save that into the webroot and then test. If you run the script from the command line using php or php-cgi, it will work. If you access the script via a webpage and tail the access log /var/log/nginx/example.access.log, you will notice that you receive the HTTP 1.1 499 response after 60 seconds.

Now that you can see the timeout, I’ll go through some of the config changes I’ve made to both PHP and NginX to try to get around this. For PHP I’ll create several config files so that they can be easily disabled

Update the PHP FPM Config to include external config files

sudo echo '
include=/usr/local/php/php-fpm.d/*.conf
' >> /usr/local/php/etc/php-fpm.conf

Create a new PHP-FPM config to override the request timeout

sudo echo '[www]
request_terminate_timeout = 120s
request_slowlog_timeout = 60s
slowlog = /var/log/php-fpm-slow.log ' >
/usr/local/php/php-fpm.d/timeouts.conf

Change some of the global settings to ensure the emergency restart interval is 2 minutes

# Create a global tweaks
sudo echo '[global]
error_log = /var/log/php-fpm.log
emergency_restart_threshold = 10
emergency_restart_interval = 2m
process_control_timeout = 10s
' > /usr/local/php/php-fpm.d/global-tweaks.conf

Next, we will change some of the PHP.INI settings, again using separate files

# Log PHP Errors
sudo echo '[PHP]
log_errors = on
error_log = /var/log/php.log
' > /usr/local/php/conf.d/errors.ini

sudo echo '[PHP]
post_max_size=32M
upload_max_filesize=32M
max_execution_time = 360
default_socket_timeout = 360
mysql.connect_timeout = 360
max_input_time = 360
' > /usr/local/php/conf.d/filesize.ini

As you can see, this is increasing the socket timeout to 3 minutes and will help log errors.

Finally, I’ll edit some of the NginX settings to increase the timeout’s that side

First I edit the file /etc/nginx/nginx.conf and add this to the http directive
fastcgi_read_timeout 300;

Next, I edit the file /etc/nginx/sites-enabled/example which we created earlier (See the pastebin entry) and add the following settings into the server directive

client_max_body_size    200;
client_header_timeout   360;
client_body_timeout     360;
fastcgi_read_timeout    360;
keepalive_timeout       360;
proxy_ignore_client_abort on;
send_timeout            360;
lingering_timeout       360;

Finally I add the following into the location ~ .php$ section of the server dir

fastcgi_read_timeout 360;
fastcgi_send_timeout 360;
fastcgi_connect_timeout 1200;

Before retrying the script, start both nginx and php-fpm to ensure that the new settings have been picked up. I then try accessing the page and still receive the HTTP/1.1 499 entry within the NginX example.error.log.

So, where am I going wrong? This just works on apache when I set PHP’s max execution time to 2 minutes.

I can see that the PHP settings have been picked up by running phpinfo() from a web-accessible page. I just don’t get, I actually think that too much has been increased as it should just need PHP’s max_execution_time, default_socket_timeout changed as well as NginX’s fastcgi_read_timeout within just the server->location directive.

Update 1

Having performed some further test to show that the problem is not that the client is dying I have modified the test file to be

<?php
file_put_contents('/www/log.log', 'My first data');
sleep(70);
file_put_contents('/www/log.log','The sleep has passed');
die('Hello World after sleep');
?>

If I run the script from a web page then I can see the content of the file be set to the first string. 60 seconds later the error appears in the NginX log. 10 seconds later the contents of the file changes to the 2nd string, proving that PHP is completing the process.

Update 2

Setting fastcgi_ignore_client_abort on; does change the response from a HTTP 499 to a HTTP 200 though nothing is still returned to the end client.

Update 3

Having installed Apache and PHP (5.3.10) onto the box straight (using apt) and then increasing the execution time the problem does appear to also happen on Apache as well. The symptoms are the same as NginX now, a HTTP200 response but the actual client connection times out before hand.

I’ve also started to notice, in the NginX logs, that if I test using Firefox, it makes a double request (like this PHP script executes twice when longer than 60 seconds). Though that does appear to be the client requesting upon the script failing

Нажмите выше“Код Сельское хозяйство Программирование Усовершенствованные ноты”，выбирать»Top или Star Standard”

/*
* HTTP does not define the code for the case when a client closed
* the connection while we are processing its request so we introduce
* own code to log such situation when a client has closed the connection
* before we even try to send the HTTP header to it
*/
#define NGX_HTTP_CLIENT_CLOSED_REQUEST     499

curl -m 20 "http://somewebsite.com"  

top - 16:59:03 up 334 days, 23:10,  1 user,  load average: 0.06, 0.08, 0.07
Tasks: 114 total,   2 running, 112 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.5 us,  0.3 sy,  0.0 ni, 98.5 id,  0.7 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  2916192 total,   516184 free,  1540972 used,   859036 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   999988 avail Mem


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                     
11475 work      20   0  157680   2188   1520 R   0.7  0.1   0:00.34 top                                                                         
12206 elastic+  20   0 3685272 980.1m    272 S   0.7 34.4   1027:58 java                                                                        
24451 mysql     20   0 1745372 275176   2892 S   0.3  9.4 761:20.55 mysqld                                                                      
    1 root      20   0  232328  46328   1324 S   0.0  1.6  33:03.32 systemd                                                                     
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.80 kthreadd                                                                    
    3 root      20   0       0      0      0 S   0.0  0.0   0:37.02 ksoftirqd/0                                                                 
    5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H                                                                
    7 root      rt   0       0      0      0 S   0.0  0.0   0:20.47 migration/0                                                                 
    8 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_bh                                                                      
    9 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/0                                                                     
   10 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/1                                                                     
   11 root      20   0       0      0      0 R   0.0  0.0 126:24.86 rcu_sched

PM = Dynamic Как контролировать дочерние процессы, варианты со статическими и динамическими
 PM.MAX_CHILDREN: количество процессов PHP-FPM в статическом режиме
 PM.max_requests: максимальное количество запросов на подпрограмм PHP-FPM можно обрабатывать
 PM.START_SERVERS: количество запуска процессов PHP-FPM в динамическом режиме
 PM.MIN_SPARE_SERVERS: Минимальный процесс PHP-FPM в динамическом режиме
 PM.max_spare_servers: количество максимальных процессов PHP-FPM в динамическом режиме

In my case, I was impatient and ended up misinterpreting the log.

In fact, the real problem was the communication between nginx and uwsgi, and not between the browser and nginx. If I had loaded the site in my browser and had waited long enough I would have gotten a «504 — Bad Gateway». But it took so long, that I kept trying stuff, and then refresh in the browser. So I never waited long enough to see the 504 error. When refreshing in the browser, that is when the previous request is closed, and Nginx writes that in the log as 499.

Elaboration

Here I will assume that the reader knows as little as I did when I started playing around.

My setup was a reverse proxy, the nginx server, and an application server, the uWSGI server behind it. All requests from the client would go to the nginx server, then forwarded to the uWSGI server, and then response was sent the same way back. I think this is how everyone uses nginx/uwsgi and are supposed to use it.

My nginx worked as it should, but something was wrong with the uwsgi server. There are two ways (maybe more) in which the uwsgi server can fail to respond to the nginx server.

1) uWSGI says, «I’m processing, just wait and you will soon get a response». nginx has a certain period of time, that it is willing to wait, fx 20 seconds. After that, it will respond to the client, with a 504 error.

2) uWSGI is dead, or uWSGi dies while nginx is waiting for it. nginx sees that right away and in that case, it returns a 499 error.

I was testing my setup by making requests in the client (browser). In the browser nothing happened, it just kept hanging. After maybe 10 seconds (less than the timeout) I concluded that something was not right (which was true), and closed the uWSGI server from the command line. Then I would go to the uWSGI settings, try something new, and then restart the uWSGI server. The moment I closed the uWSGI server, the nginx server would return a 499 error.

So I kept debugging with the 499 erroe, which means googling for the 499 error. But if I had waited long enough, I would have gotten the 504 error. If I had gotten the 504 error, I would have been able to understand the problem better, and then be able to debug.

So the conclusion is, that the problem was with uWGSI, which kept hanging («Wait a little longer, just a little longer, then I will have an answer for you…»).

How I fixed that problem, I don’t remember. I guess it could be caused by a lot of things.

Модераторы: Art.i, garry

Вернуться в Вопросы о работе сервера

Кто сейчас на форуме

Сейчас этот форум просматривают: Google [Bot] и гости: 0

В моем случае я был нетерпелив и в конечном итоге неправильно истолковал журнал.

На самом деле настоящей проблемой была связь между nginx и uwsgi, а не между браузером и nginx. Если бы я загрузил сайт в свой браузер и подождал достаточно долго, я бы получил «504 — Bad Gateway». Но это заняло так много времени, что я все пробовал, а потом обновлял в браузере. Поэтому я никогда не ждал достаточно долго, чтобы увидеть ошибку 504. При обновлении в браузере, то есть когда предыдущий запрос закрывается, а Nginx пишет что в логе как 499.

Разработка

Здесь я предполагаю, что читатель знает так же мало, как и я, когда начал экспериментировать.

Моя установка была обратным прокси-сервером, сервером nginx и сервером приложений, сервером uWSGI за ним. Все запросы от клиента отправлялись на сервер nginx, затем перенаправлялись на сервер uWSGI, а затем ответ отправлялся таким же образом обратно. Я думаю, что именно так все используют nginx/uwsgi и должны его использовать.

У меня nginx работал как надо, а вот с сервером uwsgi что-то не так. Есть два способа (а может и больше), из-за которых сервер uwsgi может не ответить серверу nginx.

1) uWSGI говорит: «Я обрабатываю, просто подождите, и вы скоро получите ответ». У nginx есть определенный период времени, который он готов ждать, например, 20 секунд. После этого он ответит клиенту с ошибкой 504.

2) uWSGI мертв, или uWSGi умирает, пока его ждет nginx. nginx сразу это видит и в таком случае возвращает ошибку 499.

Я тестировал свою настройку, делая запросы в клиенте (браузере). В браузере ничего не происходило, просто висело. Примерно через 10 секунд (меньше тайм-аута) я пришел к выводу, что что-то не так (что было правдой), и закрыл сервер uWSGI из командной строки. Затем я заходил в настройки uWSGI, пробовал что-то новое, а затем перезапускал сервер uWSGI. В тот момент, когда я закрыл сервер uWSGI, сервер nginx вернул ошибку 499.

Поэтому я продолжал отладку с ошибкой 499, что означает поиск ошибки 499 в Google. Но если бы я ждал достаточно долго, я бы получил ошибку 504. Если бы я получил ошибку 504, я бы лучше понял проблему, а затем смог бы ее отладить.

Отсюда вывод, что проблема была с uWGSI, который все время зависал («Подожди еще немного, еще немного, тогда я тебе отвечу…»).

Как я исправил который проблема, не помню. Я думаю, это может быть вызвано многими вещами.

400 Bad Request

Запрос не был распознан сервером из-за возможной ошибки синтаксиса. Клиент не должен повторно отправлять этот запрос без модификации.

Запрос требует авторизации пользователя¹⁾. С этим статусом сервер должен отправить в заголовке поле WWW-Authenticate с запросом авторизации. Клиент может повторно отправить свой запрос с включением в заголовок реквизитов авторизации (поле Authorization). Если запрос клиента уже содержал заголовок с реквизитами, ответ 401 означает, что реквизиты неверны и авторизация не состоялась. При получении статуса 401 пользователю должна быть представлена форма для ввода реквизитов доступа.

402 Payment Required

Данный ответ подразумевает оплату доступа к ресурсу. Не используется, зарезервирован для применения в будущем²⁾.

403 Forbidden

Доступ запрещен. Сервер распознал запрос, но в доступе отказано. Отказ не связан с авторизацией, а обусловлен настройками сервера, клиент не должен повторять запрос к запрещенной области. Сервер должен отправить сообщение с объяснением отказа. Если доступ невозможен временно и сообщение о запрете нежелательно, то вместо этого статуса нужно использовать 404.

404 Not Found

В данный момент документ недоступен. Сервер не находит документа, соответствующего запрошенному URI. При этом не уточняется, постоянно или временно отсутствует доступ. Такой статус обычно отправляется, когда невозможно сообщить точную причину отказа и неприменим никакой более точный ответ. Если известно, что документ по этому адресу больше не существует, сервер должен отправлять вместо этого статуса 410 Gone.

405 Method Not Allowed

Метод доступа, указанный в запросе, не разрешен для ресурса, адресуемого запрошенным URI. Ответ сервера должен включать поле заголовка Allow, содержащее список допустимых методов для данного ресурса.

406 Not Acceptable

407 Proxy Authentication Required

Этот ответ аналогичен 401, но требует от клиента авторизации на прокси-сервере. Прокси должен прислать в ответе поле заголовка Proxy-Authenticate, клиент может повторить запрос с соответствующим полем заголовка Proxy-Authorization. В остальном действует та же процедура HTTP-авторизации.

408 Request Timeout

Клиент не послал запрос в течение того интервала времени, когда сервер его ожидал. Запрос может быть отправлен повторно.

409 Conflict

Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса. Такой статус применим в тех редких случаях, когда на сервере реализован метод PUT и выполнение PUT-запроса вызывает конфликт с результатом предыдущего запроса.

410 Gone

411 Length Required

Сервер отказал в доступе по запросу с не определенным полем Content-Length в заголовке. Клиент может повторить запрос, если добавит в заголовок поле Content-Length с указанием длины «тела» запроса. Обычно применимо для POST-запросов.

412 Precondition Failed

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

413 Request Entity Too Large

Сервер отказывает в обработке запроса, поскольку запрошенный объект слишком велик — больше, чем сервер в состоянии обработать. Сервер может закрыть соединение, чтобы помешать клиенту продолжать запрос. Если это состояние является временным, сервер должен включить в заголовок ответа поле Retry-After с указанием, через какое время клиент может попытаться повторить запрос.

414 Request-URI Too Long

415 Unsupported Media Type

Формат объекта запроса не поддерживается запрашиваемым ресурсом для данного метода запроса.

416 Requested Range Not Satisfiable

417 Expectation Failed

Наверх