Ошибка 406 http сервис 1с

22.04.2016

Повышение производительности веб-сервисов

Реализовано в версии 8.3.9.1818.

В версии 8.3.9 мы выполнили значительное количество задач по оптимизации разных механизмов платформы. Здесь хочется рассказать об одной из них. Это повышение производительности веб-сервисов.

Переиспользование сеансов

Недостаточная производительность веб-сервисов объяснялась тем, что каждый вызов веб-сервиса имел значительные накладные расходы на создание и завершение сеанса. Причём при создании каждый раз выполнялся обработчик УстановкаПараметровСеанса(), который в типовой конфигурации может быть довольно «тяжёлым».

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

В версии 8.3.9 мы доработали механизм веб-сервисов (SOAP-сервисы, HTTP-сервисы, сервисы OData). В результате их производительность увеличилась примерно в 10 раз.

Мы проводили тесты на типовой конфигурации Бухгалтерия предприятия. В неё мы добавили HTTP-сервисы, выполняющие выборку из справочника Контрагенты. Тест заключался в том, что клиент выполнял последовательно 100 обращений к сервису. В старом режиме работы для этого потребовалось 29,9 с. В новых режимах работы в среднем 3 с.

Этих результатов удалось достичь за счёт того, что мы реализовали две различные стратегии, обеспечивающие переиспользование сеансов:

• Автоматическое переиспользование сеансов из пула;
• Управление сеансами с помощью HTTP-заголовков.

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

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

Другой пример это получение/помещение файлов в конфигурации Документооборот посредством http-сервисов. Для таких операций можно использовать одного и того же специального пользователя.

Стратегия ручного управления сеансами подразумевает, что клиент самостоятельно управляет количеством сеансов и временем их жизни. Эта стратегия лучше подходит для высокоинтегрированных систем в рамках одной организации. Вы можете реализовать собственный алгоритм, который будет управлять временем жизни сеансов и их количеством.

Средства управления

Необходимость использования одной или другой стратегии вы можете определить в дереве объектов конфигурации, и, при необходимости, переопределить в файле публикации default.vrd. В дереве объектов конфигурации мы добавили два новых свойства объектам Web-сервис и HTTP-сервис:

• ПовторноеИспользованиеСеансов может принимать значения ИспользоватьАвтоматически, Использовать, НеИспользовать. Значение ИспользоватьАвтоматически включает автоматическое переиспользование сеансов из пула, а значение Использовать включает управление сеансами с помощью HTTP-заголовков.
• В свойстве ВремяЖизниСеанса вы можете указать, сколько секунд будет бездействовать сеанс до того, как платформа завершит его автоматически.

В файле default.vrd для элементов, описывающих SOAP-сервисы, HTTP-сервисы и сервисы OData, мы ввели несколько новых атрибутов:

• reuseSessions – аналог свойства ПовторноеИспользованиеСеансов, может принимать значения autouse, use и dontuse;
• sessionMaxAge — аналог свойства ВремяЖизниСеанса;
• poolTimeout — используется при автоматическом управлении сеансами, содержит время ожидания доступности сеанса;
• poolSize — используется при автоматическом управлении сеансами, содержит максимальное количество сеансов, которое может быть создано в пуле.

Например, файл default.vrd может выглядеть так:

<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://testserver/Demo83"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                    base="/demo"
                    ib="Srvr=&quot;tcp://Server&quot;;Ref=&quot;demo&quot;;"
                    enable="false"
                    allowexecutescheduledjobs="force"
                    enableStandardOData="true">
        <standardOdata enable="true" reuseSessions="use" sessionMaxAge ="20" poolTimeout="5" poolSize="10"/>
    <ws>
        <point name="OperationalData1" alias="OperData" reuseSessions="use" sessionMaxAge="20" poolTimeout="5" poolSize="10"/>
    </ws>
    <httpServices>
        <service name="ПримерРаботы" enable="true" reuseSessions ="autouse" sessionMaxAge="20" poolTimeout="5" poolSize="10"/>
    </httpServices>
    <pool size="50" maxAge="10" attempts="2"/>
</point>



  


                       
  

Файл default.vrd имеет больший приоритет, чем конфигурация. При публикации конфигурации атрибуты reuseSessions и sessionMaxAge заполняются из соответствующих свойств объектов конфигурации Web-сервис и HTTP-сервис. Но при необходимости вы можете изменить эти значения прямо в файле, и тогда платформа будет использовать их, а не значения из конфигурации.

Автоматическое переиспользование сеансов

Сеансы в пуле хранятся в разрезе типа сервиса, наименования сервиса, пользователя/пароля, значений разделителей и безопасного режима. Причём в пуле может быть несколько сеансов с одинаковыми значениями перечисленных реквизитов.

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

Сеанс автоматически завершается по истечении периода бездействия (ВремяЖизниСеанса).

Если достигнуто максимальное количество сеансов (poolSize), то вызов ждет указное время (poolTimeout). Если за это время подходящий сеанс не освободился, то возвращается ошибка со статусом 406 Not Acceptable.

Настройки автоматического пула сеансов действуют в рамках публикации. Это значит, что если у вас есть несколько публикаций для одной и той же информационной базы, то при вызове действуют те параметры, которые указаны в публикации, к которой обращается текущий вызов. Таким образом, если в одной публикации для сервиса указан лимит в 3 сеанса, а в другой публикации 5, то общее количество сеансов, которое может быть создано для вашей информационной базы равняется сумме этих значений 8.

При выборе размера пула следует учитывать все разрезы, в которых хранятся сеансы в пуле. Мы рекомендуем устанавливать размер пула немного больше, чем количество возможных вариантов. Это позволит вам избежать ситуации, когда пул заполнен сеансами, и вызов с новой комбинацией разделителей/пользователей обработан быть не может.

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

Управление сеансами

Инициатором создания и завершение сеанса является клиент сервиса. Чтобы создать постоянный сеанс клиент должен передать заголовок IBSession в http – запросе. Этот заголовок вы устанавливаете вручную. Значением этого заголовка должна быть директива start.

POST http://testserver/Demo83/ws/ws2.1cws HTTP/1.1
…
Connection: Keep-Alive
Content-Type: text/xml;charset="utf-8"
SOAPAction: http://testserver/Demo83/ws2#Web      1:        1
IBSession: start
Content-Length: 182
…

После получения такого заголовка на сервере стартует сеанс информационной базы, происходит аутентификация, установка разделителей и вызывается обработчик УстановкаПараметровСеанса().

Если клиент затребовал создание сеанса, а сервер не может это сделать, генерируется сообщение об ошибке 406 Not Acceptable.

Если всё хорошо и сеанс создан, платформа помещает в http-ответ директиву установки куки IBSession с идентификатором созданного сеанса.

HTTP/1.1 200 OK
Date: Thu, 02 Apr 2015 06:31:11 GMT
Server: Apache/2.0.65 (Win32)
Content-Length: 357
Keep-Alive: timeout=15, max=100
Set-Cookie: IBSession=43CD8102-F970-4FFB-939A-C47948F49885
Connection: Keep-Alive
Content-Type: text/xml;charset="utf-8"
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
	<soap:Body>
		<m:Операция1Response xmlns:m="http://testserver/Demo83/ws2">
			<m:return xmlns:xs="http://www.w3.org/2001/XMLSchema"
					xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">true</m:return>
		</m:Операция1Response>
	</soap:Body>
</soap:Envelope>

Для подключения ранее созданного сеанса, вам необходимо указать куки IBSession с идентификатором сеанса.

HTTP/1.1 200 OK
Date: Thu, 02 Apr 2015 06:31:12 GMT
Server: Apache/2.0.65 (Win32)
Content-Length: 357
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Cookie: IBSession=43CD8102-F970-4FFB-939A-C47948F49885
Content-Type: text/xml;charset="utf-8"
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
	<soap:Body>
		<m:Операция1Response xmlns:m="http://testserver/Demo83/ws2">
			<m:return xmlns:xs="http://www.w3.org/2001/XMLSchema"
					xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">true</m:return>
		</m:Операция1Response>
	</soap:Body>
</soap:Envelope>

Для завершения сеанса вам нужно использовать заголовок IBSession http-запроса. Его нужно установить в директиву finish.

POST http://testserver/Demo83/ws/ws2.1cws HTTP/1.1
…
Connection: Keep-Alive
Content-Type: text/xml;charset="utf-8"
SOAPAction: http://testserver/Demo83/ws2#Web      1:        1
IBSession: finish
Content-Length: 182

Получив сообщение с таким заголовком, сервер отрабатывает вызов, и закрывает сеанс.

Эта стратегия позволяет вам реализовать сценарии, в которых используется состояние сеанса, сохранённое на сервере. Потому что вы имеете уникальный идентификатор сеанса. Единственное, о чём нужно помнить, что завершение сеанса может происходить не только по вашей «команде», но и автоматически. В том случае, когда превышен период бездействия сеанса (ВремяЖизниСеанса). Поэтому вы, как клиент сервиса, должны быть готовы к тому, что сеансовые данные могут быть сброшены, если сеанс завершен.

Веб-сервисы в расширениях

Если объекты конфигурации Web-сервис или HTTP-сервис располагается в расширении конфигурации, то возможность редактировать свойства ПовторноеИспользованиеСеансов и ВремяЖизниСеанса у вас отсутствует. Поэтому, если вы хотите включить автоматическое или ручное переиспользование сеансов, вам нужно использовать для этого файл default.vrd.

В дальнейшем мы будем рассматривать возможность поддержки этих свойств в расширениях.

Теги:
веб-сервисы 
производительность 
расширения 
8.3.9 

Здравствуйте.

Ситуация следующая. Собрал конфигурацию из базовых подсистем БСП, дописал свои объекты, создал Web-сервис, при первой публикации Web-сервис работал без ошибок, потребовалось внести незначительные изменения, стал выдавать ошибку:

Часть 2. Тестирование и отладка HTTP-сервиса с помощью SoapUI

Разработаем HTTP-сервис, который по уникальному идентификатору номенклатуры будет возвращать остаток этой номенклатуры на складе. HTTP-сервис должен отвечать следующим требованиям:

1. Формат запроса и ответа — JSON;
2. Запрос принимается методом POST;
3. В заголовках запроса должна присутствовать информация о клиенте (клиент — другая информационная система);
4. Сервис должен быть версионируемым (что бы клиенты не страдали от изменений в сервисе, а по возможности переходили на следующую версию).

Первым делом, создаем HTTP-сервис HTTPСервисОстатки, в корневом URL указываем значение balance.

Рисунок 1. Основные свойства http-сервиса

В шаблонах URL добавляем шаблон /nomenclature/{version} под именем Номенклатура. В шаблоне имеется параметр version, который заключен в фигурные скобки, он нам нужен, что бы выполнить требование №4 (см. рисунок 2).

Рисунок 2. Шаблон URL

Для шаблона добавляем HTTP-метод POST и создаем обработчик для этого метода, это требование №2 (см. рисунок 3).

Рисунок 3. HTTP-метод POST

В разрабатываемый HTTP-сервис закладываем две версии — первая будет доступна по url: /nomenclature/v1 и вторая по url: /nomenclature/v2. Первая версия будет работать только с одним уникальным идентификатором номенклатуры, а вторая версия с массивом уникальных идентификаторов. Структура JSON-строки запроса и ответа для каждой версии приведены в таблице ниже.

{
  "Период": "",
  "UUID": ""
}
      

{
  "Период": "",
  "UUID": []
}
      

{
  "Версия": 0,
  "НаДату": "",
  "Остаток": 0
}
      

{
   "Версия": 0,
   "НаДату": "",
   "Остатки": [
     {
      "UUID": "",
      "Остаток": 0
     }
   ],
   "Резерв": null
}
      

Приступим к программной реализации обработчика HTTP-метода POST.

Если клиент обращается к неизвестной версии HTTP-сервиса, то необходимо об этом как-то ему сообщить, да что бы было понятно в чем дело, поэтому для выполнения требования №4, не достаточно ввести параметр version в шаблон URL, его значение нужно дополнительно анализировать в обработчике HTTP-метода. В случае неизвестного значения  возвращаем в ответ ошибку 404 с описанием причины, что такой URL серверу неизвестен или версия сервиса неизвестна.

	
// Определение запрашиваемой версии сервиса.
// Если версия не известна, то отклоняем запрос с описанием причины.
ДопустимыеВерсииСервиса	= "v1,v2";
ВерсияСервиса = Запрос.ПараметрыURL["version"];
Если СтрРазделить(ДопустимыеВерсииСервиса, ",").Найти(ВерсияСервиса) = Неопределено Тогда 
    Ответ = Новый HTTPСервисОтвет(404);
    Ответ.УстановитьТелоИзСтроки(НСтр("ru = 'Версия не существует'"));
    Возврат Ответ;
КонецЕсли;
  

Что бы выполнить требование №1, проверяем в заголовках HTTP-запроса наличие заголовка Content-Type, его значение должно равняться application/json. Это стандартный заголовок и один из самых известных, используется для определения типа передаваемых данных. Если данный заголовок будет отсутствовать, то по умолчанию считаем что пришли данные типа текст в формате JSON, иначе анализируем значение заголовка и принимаем решение, если это не текстовые данные в формате JSON, выкидываем в ответ ошибку с кодом 415.

	
// Чтение значения заголовка Content-Type.
// Если значение заголовка не соответствует допустимому,
// то отклоняем запрос с описанием причины.
ТипДопустимогоКонтента = "application/json";
ContentType = Запрос.Заголовки.Получить("Content-Type");
Если ContentType <> Неопределено Тогда
    Если СтрНайти(ContentType, ТипДопустимогоКонтента) = 0 Тогда 
        Ответ = Новый HTTPСервисОтвет(415);
        Ответ.УстановитьТелоИзСтроки(НСтр("ru = 'Ожидаемый формат - JSON'"));
        Возврат Ответ;
    КонецЕсли;
КонецЕсли;
  

Что бы выполнить требование №3, проверяем в заголовках HTTP-запроса наличие заголовка Client-Name-1C, это собственный заголовок, мы его придумали сами и используем для своих целей, допустим, фиксируем в журнале регистрации значение заголовка. Наличие данного заголовка обязательно, если он отсутствует, то выкидываем в ответ ошибку с кодом 406.

	
// Чтение обязательного заголовка Client-Name-1C.
ClientName1C = Запрос.Заголовки.Получить("Client-Name-1C");
Если ClientName1C = Неопределено Тогда
    Ответ = Новый HTTPСервисОтвет(406);
    Ответ.УстановитьТелоИзСтроки(НСтр("ru = 'Отсутствует обязательный заголовок'"));
    Возврат Ответ;
Иначе 
    // Запись в журнал регистрации о клиенте.
    // ...
КонецЕсли;
  

Теперь самое основное, реализуем логику работы HTTP-сервиса. Получаем тело HTTP-запроса как строку, в нашем случает это JSON-строка (см. требование №1). Что бы было удобно работать с данными, которые содержит в себе JSON-строка, читаем JSON-строку в коллекцию значений. Спасибо разработчикам платформы 1С за процедуры и функции по работе с JSON, которые появились в версии 8.3.

	
// Читаем тело запроса как JSON-строку.
СтроковоеТело = Запрос.ПолучитьТелоКакСтроку();
ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(СтроковоеТело);
// Когда задана функция восстановления, то третий параметр игнорируется, хотя в СП написано наоборот.
ДанныеЗапроса = ПрочитатьJSON(ЧтениеJSON, , , , "ФункцияВосстановленияЗначений", РаботаJSON);
ЧтениеJSON.Закрыть();
  

Для каждой версии HTTP-сервиса (см. требование №4) пишем код в соответствии с логикой работы каждой версии. В первой версии работаем с одним уникальным идентификатором, во второй с массивом. Данные для ответа формируем в виде коллекции значений.

ДанныеОтвета = Новый Структура;
Если ВерсияСервиса = "v1" Тогда 

    // Обрабатываем запрос.
    Период = ДанныеЗапроса.Период;
    Номенклатура = Справочники.Номенклатура.ПолучитьСсылку(ДанныеЗапроса.UUID);

    // Выполняем расчет остатков.
    // ...
		
    // Формируем ответ.
    ДанныеОтвета.Вставить("Версия", 1.04);
    ДанныеОтвета.Вставить("НаДату", Период);
    ДанныеОтвета.Вставить("Остаток", 10);

ИначеЕсли ВерсияСервиса = "v2" Тогда

    // Обрабатываем запрос.
    Период = ДанныеЗапроса.Период;
    СписокНоменклатур = Новый Массив;
    Для Каждого ТекЭлемент Из ДанныеЗапроса.UUID Цикл 
        СписокНоменклатур.Добавить(Справочники.Номенклатура.ПолучитьСсылку(ТекЭлемент));
    КонецЦикла;

    // Выполняем расчет остатков.
    // ...

    ОстаткиПоНоменклатурам = Новый Массив;
    Для Каждого ТекЭлемент Из СписокНоменклатур Цикл 
        Остаток = Новый Структура("UUID,Остаток", ТекЭлемент.УникальныйИдентификатор(), 10);
        ОстаткиПоНоменклатурам.Добавить(Остаток);
    КонецЦикла;

    // Формируем ответ.
    ДанныеОтвета.Вставить("Версия", 2.15);
    ДанныеОтвета.Вставить("НаДату", Период);
    ДанныеОтвета.Вставить("Остатки", ОстаткиПоНоменклатурам);

КонецЕсли;
  

Сформированные данные для ответа записываем в JSON-строку, на основании которой создаем HTTP-ответ с кодом 200. В заголовках HTTP-ответа обязательно указываем заголовок Content-Type, что бы клиент точно знал тип данных и их формат в ответе.

	
// Сохраняем ответ в формате JSON-строки.
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, ДанныеОтвета, , "ФункцияПреобразованияЗначений", РаботаJSON);	
СтроковоеТело = ЗаписьJSON.Закрыть();

// Отвечаем.
Ответ = Новый HTTPСервисОтвет(200);
Ответ.Заголовки.Вставить("Content-Type", ТипДопустимогоКонтента + "; charset=utf-8");
Ответ.УстановитьТелоИзСтроки(СтроковоеТело);
  

В запросе и ответе участвуют уникальные идентификаторы. Проблема в том, что 1Сные процедуры и функции по работе с JSON не умеют преобразовывать уникальный идентификатор из строки в тип УникальныйИдентификатор и обратно, но их этому можно научить. Делается это с помощью параметра ИмяФункцииПреобразования для процедуры ЗаписатьJSON и с помощью параметра ИмяФункцииВосстановления для процедуры ПрочитатьJSON. Реализацию функций для перечисленных параметров рассматривать не будем, так как это выходит за рамки создания HTTP-сервиса.

Полный код обработчика для метода POST:

	
Функция ШаблонURLМетодPOST(Запрос)
    
    // Определение запрашиваемой версии сервиса.
    // Если версия неизвестна, то отклоняем запрос с описанием причины.
    ДопустимыеВерсииСервиса = "v1,v2";
    ВерсияСервиса = Запрос.ПараметрыURL["version"];
    Если СтрРазделить(ДопустимыеВерсииСервиса, ",").Найти(ВерсияСервиса) = Неопределено Тогда 
        Ответ = Новый HTTPСервисОтвет(404);
        Ответ.УстановитьТелоИзСтроки(НСтр("ru = 'Версия не существует'"));
        Возврат Ответ;
    КонецЕсли;
    
    // Чтение значения заголовка Content-Type.
    // Если значение заголовка не соответствует допустимому,
    // то отклоняем запрос с описанием причины.
    ТипДопустимогоКонтента = "application/json";
    ContentType = Запрос.Заголовки.Получить("Content-Type");
    Если ContentType <> Неопределено Тогда
        Если СтрНайти(ContentType, ТипДопустимогоКонтента) = 0 Тогда 
            Ответ = Новый HTTPСервисОтвет(415);
            Ответ.УстановитьТелоИзСтроки(НСтр("ru = 'Ожидаемый формат - JSON'"));
            Возврат Ответ;
        КонецЕсли;
    КонецЕсли;
    
    // Чтение обязательного заголовка Client-Name-1C.
    ClientName1C = Запрос.Заголовки.Получить("Client-Name-1C");
    Если ClientName1C = Неопределено Тогда
        Ответ = Новый HTTPСервисОтвет(406);
        Ответ.УстановитьТелоИзСтроки(НСтр("ru = 'Отсутствует обязательный заголовок'"));
        Возврат Ответ;
    Иначе 
        // Запись в журнал регистрации о клиенте.
        // ...
    КонецЕсли;
    
    // Читаем тело запроса как JSON-строку.
    СтроковоеТело = Запрос.ПолучитьТелоКакСтроку();
    ЧтениеJSON = Новый ЧтениеJSON;
    ЧтениеJSON.УстановитьСтроку(СтроковоеТело);
    // Когда задана функция восстановления, то третий параметр игнорируется, хотя в СП написано наоборот.
    ДанныеЗапроса = ПрочитатьJSON(ЧтениеJSON, , , , "ФункцияВосстановленияЗначений", РаботаJSON);
    ЧтениеJSON.Закрыть();
    
    ДанныеОтвета = Новый Структура;
    Если ВерсияСервиса = "v1" Тогда 
        
        // Обрабатываем запрос.
        Период = ДанныеЗапроса.Период;
        Номенклатура = Справочники.Номенклатура.ПолучитьСсылку(ДанныеЗапроса.UUID);
        
        // Выполняем расчет остатков.
        // ...
        
        // Формируем ответ.
        ДанныеОтвета.Вставить("Версия", 1.04);
        ДанныеОтвета.Вставить("НаДату", Период);
        ДанныеОтвета.Вставить("Остаток", 10);
        
    ИначеЕсли ВерсияСервиса = "v2" Тогда
        
        // Обрабатываем запрос.
        Период = ДанныеЗапроса.Период;
        СписокНоменклатур = Новый Массив;
        Для Каждого ТекЭлемент Из ДанныеЗапроса.UUID Цикл 
            СписокНоменклатур.Добавить(Справочники.Номенклатура.ПолучитьСсылку(ТекЭлемент));
        КонецЦикла;
        
        // Выполняем расчет остатков.
        // ...
        
        ОстаткиПоНоменклатурам = Новый Массив;
        Для Каждого ТекЭлемент Из СписокНоменклатур Цикл 
            Остаток = Новый Структура("UUID,Остаток", ТекЭлемент.УникальныйИдентификатор(), 10);
            ОстаткиПоНоменклатурам.Добавить(Остаток);
        КонецЦикла;
        
        // Формируем ответ.
        ДанныеОтвета.Вставить("Версия", 2.15);
        ДанныеОтвета.Вставить("НаДату", Период);
        ДанныеОтвета.Вставить("Остатки", ОстаткиПоНоменклатурам);
        
    КонецЕсли;
    
    // Задаем настройки для записи коллекции значений в JSON-строку.
    НастройкиСериализацииJSON = Новый НастройкиСериализацииJSON;
    НастройкиСериализацииJSON.ВариантЗаписиДаты                 = ВариантЗаписиДатыJSON.ЛокальнаяДатаСоСмещением;
    НастройкиСериализацииJSON.СериализовыватьМассивыКакОбъекты  = Ложь;
    НастройкиСериализацииJSON.ФорматСериализацииДаты            = ФорматДатыJSON.ISO;
    
    // Сохраняем ответ в формате JSON-строки.
    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    ЗаписатьJSON(ЗаписьJSON, ДанныеОтвета, НастройкиСериализацииJSON, "ФункцияПреобразованияЗначений", РаботаJSON); 
    СтроковоеТело = ЗаписьJSON.Закрыть();
    
    // Отвечаем.
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.Заголовки.Вставить("Content-Type", ТипДопустимогоКонтента + "; charset=utf-8");
    Ответ.УстановитьТелоИзСтроки(СтроковоеТело);    
    
    Возврат Ответ;
    
КонецФункции
  

Код состояния HTTP — это часть строки заголовка, ответа веб сервера на запрос клиента, информирующая о результате запроса и о том, что клиент должен предпринять далее

Код состояния HTTP — это часть строки заголовка, ответа веб сервера на запрос клиента, информирующая о результате запроса и о том, что клиент должен предпринять далее. Думаю не все знают как выглядит заголовок ответа сервера, зато уверен, каждый, пользующийся интернетом, не раз сталкивались, со страницей 404 Not Found или 403 Forbadden. Это и есть, видимый пользователю результат, выдачи сервером, того или иного кода статуса в строке заголовке.

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

1xx: Information — информационные

100 Continue — Продолжать.

Сервер доволен данными в запросе клиента, можно продолжать передачу заголовков. Появился в протоколе версии HTTP/1.1.

101 Switching Protocols — Переключение протоколов.

Сервер предлагает выбрать другой протокол, более соответствующий данному ресурсу. Протоколы предлагаемый сервером, указываются в строке заголовка Update, если предложенный сервером протокол, устраивает клиента, он высылает новый запрос с указанием нового протокола. Появился в протоколе версии HTTP/1.1.

102 Processing — Обрабатывается.

Используется в протоколе WebDAV, работающем поверх HTTP протокола. Данный код статуса информирует клиента о том, что запрос принят, но на его обработку может понадобится определенное время, что-бы он ( клиент ), не сбрасывал соединение. Клиент в этом случае должен обнулить таймер и ожидать следующей команды.

2xx: Success — Успешное завершение

200 OK — Хорошо.

Запрос к ресурсу выполнен успешно. Данные, запрошенные клиентом, находятся в заголовке и/или в теле ответа. Появился в протоколе версии HTTP/1.0.

201 Created — Создано.

Запрос выполнен успешно, новый ресурс создан. В ответе сервера, в заголовке Location, указывается местоположение созданного ресурса. Кроме того, серверу рекомендуется указывать характеристики созданного ресурса, в заголовке ответа. Появился в протоколе версии HTTP/1.0.

202 Accepted — Принято.

Запрос принят, но еще в обработке. Появился в протоколе версии HTTP/1.0.

203 Non-Authoritative Information — Информация из неавторитетного источника.

Аналогично коду 200, но в данном случае информация может быть неактуальной, так как взята не из первоисточника. Появился в протоколе версии HTTP/1.1.

204 No Content — Отсутствует содержимое.

Сервер успешно обработал запрос, но не вернул содержимого. Появился в протоколе версии HTTP/1.0.

205 Reset Content — Сбросить содержимое.

Сервер успешно обработал запрос, но не вернул содержимого. В отличии от кода 204, данный код, требует от клиента, сбросить представление документа. Появился в протоколе версии HTTP/1.1.

206 Partial Content — Часть содержимого.

Сервер вернул результат запроса клиентом, части содержимого, с помощью заголовка range. Используется для докачки файлов или для многопоточной закачки. Появился в протоколе версии HTTP/1.1.

207 Multi-Status — Многостатусный.

Возвращаемое сервером тело сообщения, представляет из себя XML документ со статусами выполнения нескольких подзапросов. Используется в протоколе WebDAV.

226 IM Used — Использовано IM

Расширение HTTP для поддержки «дельта кодирования» ( delta encoding ). Заголовок A-IM принят, данные возвращаются согласно установленным параметрам.

3xx: Redirection — Редирект ( перенаправление )

Коды данной категории, сообщают клиенту, что для завершения запроса, ему необходимо выполнить дополнительный запрос, как правило по другому URI, соответствующий адрес указывается в строке Location, ответа сервера. Программа — клиент может совершать дополнительные запросы без участия пользователя, при условии что дополнительный запрос делается методами GET или HEAD.

Некоторые клиенты некорректно работают с редиректами 301 и 302, применяя в запросе ко второму ресурсу метод GET, несмотря на то, что первый запрос был сделан с использованием другого метода. В протоколеHTTP версии 1.1, вместо ответа статуса 302, были введены дополнительные коды ответов, 303 и 307. Изменять метод, необходимо только в случает ответа сервера со статусом 303, в остальных случаях использовать исходный метод.

300 Multiple Choices — Несколько вариантов выбора.

По запрошенному URI, существует несколько вариантов ресурса, различных по MIME типу. языку или другим признакам. В ответе сервера, передается список альтернатив, выбираемый клиентским приложением автоматически или самим пользователем. Появился в протоколе версии HTTP/1.0.

301 Moved Permanently — Перемещёно окончательно.

Запрошенный ресурс был окончательно перемещен на URI, указанный в строке заголовка Location, ответа сервера. Некоторые клиенты, при обработке данного кода, ведут себя некорректно, см. выше. Появился в протоколе версии HTTP/1.0.

302 Found — Найдено ( Moved Temporarily )

Данный код статуса сообщает клиенту, что ресурс временно доступен по другому URI, указанному в строке заголовка Location, заголовка ответа сервера. Данный код используется например, при согласовании содержимого ( Content Negotiation ), выполняемого сервером. Появился в протоколе версии HTTP/1.0.

303 See Other — Смотреть другое.

Документ из запрошенного URI, нужно запросить по адресу, указанному в строке заголовка Location, заголовка ответа сервера, используя метод GET, невзирая на то, каким методом был сделан первый запрос. Появился в протоколе версии HTTP/1.1.

304 Not Modified — Не изменялось.

Данный код выдается в случае запроса документа, методом GET, с использованием заголовков If-Modified-Since или If-None-Match, и документ не был изменен с указанного момента времени. Появился в протоколе версии HTTP/1.0.

305 Use Proxy — Использовать прокси сервер.

Запрос к ресурсу, должен выполняться через прокси-сервер., адрес которого, указан в строке заголовка Location, заголовка ответа сервера. Появился в протоколе версии HTTP/1.1.

307 Temporary Redirect — Временное перенаправление

Запрошенный ресурс временно доступен по URI, указанному в строке заголовка Location, заголовка ответа сервера. Появился в протоколе версии HTTP/1.1.

4xx: Client Error — Ошибка клиента

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

400 Bad Request — Плохой запрос.

Из-за синтаксической ошибки, запрос не был понят сервером. Появился в протоколе версии HTTP/1.0.

401 Unauthorized — Не авторизован.

Ресурс требует идентификации пользователя. Клиентское приложение запрашивает у пользователя данные для аутентификации ( имя, пароль ) и передает их на сервер в заголовке WWW-Authenticate. Если данные указаны не правильно, будет снова выдан этот-же код статуса. Появился в протоколе версии HTTP/1.0.

402 Payment Required — Необходима оплата.

Пока не используется. Появился в протоколе версии HTTP/1.1.

403 Forbidden — Запрещено.

Сервер отказал в доступе к запрошенному ресурсу ввиду ограничений. Ограничения могут быть любыми, установленными администратором сервера, или определенным веб приложением. Например, в целях безопасности, закрыт доступ к файлу, .htacces или .htpasswd или к закрытой директории сайта, или в случае, когда аутентификация должна производится через веб приложение ( например сайтовый движок ), ну или блокировка по IP адресу, в случае слишком частых обращений. Появился в протоколе версии HTTP/1.0.

404 Not Found — Не найдено.

Сервер не нашел запрошенный ресурс по указанному адресу. Кроме того данный код ответа можно использовать вместо 403, с целью, скрыть расположение документа, доступ к которому запрещен. Появился в протоколе версии HTTP/1.0.

405 Method Not Allowed — Метод не поддерживается.

Клиент попытался использовать метод, недопустимый для данного ресурса. Сервер передает в заголовке, строку Allow, содержащую список допустимых методов. Появился в протоколе версии HTTP/1.1.

406 Not Acceptable — Не приемлемо.

Запрошенный ресурс, не удовлетворяет, запрошенные характеристики. В случае, если запрос был сделан не методом HEAD, сервер вернет список допустимых характеристик запрошенного ресурса. Появился в протоколе версии HTTP/1.1.

407 Proxy Authentication Required — Необходима прокси авторизация.

Данный код статуса, аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Появился в протоколе версии HTTP/1.1.

408 Request Timeout — Время ожидания истекло.

Истек таймаут ожидания передачи данных, между сервером и клиентом. Появился в протоколе версии HTTP/1.1.

409 Conflict — Конфликт.

Конфликтная ситуация при обращении к ресурсу. Такое может произойти, например, при попытке одновременного изменения файла, методом PUT, несколькими клиентами. Появился в протоколе версииHTTP/1.1.

410 Gone — Удалён.

Данный ответ выдается в случае, если документ был по указанному URI, но в данный момент удален. Появился в протоколе версии HTTP/1.1.

411 Length Required — Необходима длина.

Этот код статуса говорит о том, что для данного URI, в заголовке запроса, должно быть указано значение в поле Content-Length. Появился в протоколе версии HTTP/1.1.

412 Precondition Failed — Условие «ложно.

Данный код выдается в случае, если ни одно из условных полей заголовка не было удовлетворено. Появился в протоколе версии HTTP/1.1.

413 Request Entity Too Large — Запрошены слишком большие данные.

Данный код выдается, если сервер по каким-либо причинам, не может передать, требуемый объем данных. Если это временная проблема, сервер может указать время, по истечении которого можно будет попробовать повторно запросить ресурс, в строке заголовка, Retry-After. Появился в протоколе версии HTTP/1.1.

414 Request-URI Too Long — Запрашиваемый URI слишком длинный.

Слишком длинная строка запроса. Такая ситуация может произойти, например в случае попытки, передать данные методом GET, вместо использования POST. Появился в протоколе версии HTTP/1.1.

415 Unsupported Media Type — Неподдерживаемый тип данных.

Сервер, по какой-то причине, отказался обрабатывать запрошенные данные, используемым методом. Появился в протоколе версии HTTP/1.1.

416 Requested Range Not Satisfiable — Запрашиваемый диапазон не достижим.

В строке заголовка запроса Range, установлен диапазон, выходящий за рамки запрошенного ресурса и отсутствует строка If-Range. Появился в протоколе версии HTTP/1.1.

417 Expectation Failed — Ожидаемое не приемлемо.

Сервер не может обработать строку заголовка запроса Expect. Появился в протоколе версии HTTP/1.1.

422 Unprocessable Entity — Необрабатываемый экземпляр.

Запрос принят, тип данных может быть обработан, синтаксис XML данных в теле запроса верен, но имеет место логическая ошибка, не позволяющая обработать запрос к ресурсу. Используется в протоколеWebDAV.

423 Locked — Заблокировано.

Запрошенный ресурс заблокирован от данного метода. Используется в протоколе WebDAV.

424 Failed Dependency — Невыполненная зависимость.

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

425 Unordered Collection — Беспорядочный набор.

Этот код статуса будет выдан в случае, если клиент отправил запрос обозначив положение в неотсортированной коллекции или используя порядок следования элементов отличный от серверного. Введено в черновике по WebDAV Advanced Collections Protocol.

426 Upgrade Required — Требуется обновление.

Указание сервера, клиенту, обновить протокол. Заголовок ответа, должен содержать правильно составленные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредствомHTTP.

449 Retry With — Повторить с…

Выдается в случае поступления не достаточного количества информации для обработки запроса. В заголовок ответа сервера, помещается строка Ms-Echo-Request. Введено корпорацией Microsoft дляWebDAV.

5xx: Server Error — Ошибка на стороне сервера

Коды данной категории, предназначены для ситуаций, когда обработка запроса не возможна по вине сервера. Во всех случаях, кроме использования метода HEAD, сервер должен включать в тело ответа, объяснение для пользователя.

500 Internal Server Error — Внутренняя ошибка сервера.

Любая внутренняя ошибка на стороне сервера не подпадающая под остальные ошибки из категории 5хх. Появился в протоколе версии HTTP/1.0.

501 Not Implemented — Не реализовано.

Сервер не поддерживает, необходимых для обработки запроса, возможностей. ( например не поддерживается необходимый метод обработки ). Появился в протоколе версии HTTP/1.0.

502 Bad Gateway — Плохой шлюз.

Сервер, работающий в качестве прокси или шлюза, получил сообщение о неудачное в промежуточной операции. Появился в протоколе версии HTTP/1.0.

503 Service Unavailable — Сервис недоступен.

Сервер не в состоянии обрабатывать запросы клиентов по техническим причинам. Появился в протоколе версии HTTP/1.0.

504 Gateway Timeout — Истек таймаут ожидания ответа шлюза.

Проксирующий сервер или шлюз, не дождался ответа от вышестоящего сервера для завершения обработки запроса. Появился в протоколе версии HTTP/1.0.

505 HTTP Version Not Supported — Версия HTTP протокола не поддерживается.

Сервер не поддерживает, или не может обработать, указанную в заголовке версию HTTP протокола. Появился в протоколе версии HTTP/1.0.

506 Variant Also Negotiates — Вариант тоже согласован.

Из-за не верной конфигурации, выбранный вариант указывает сам на себя, в следствии чего, связывание прерывается. Добавлено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

507 Insufficient Storage — Переполнение хранилища.

Недостаточно места для обработки текущего запроса. Возможно временная проблема. Используется в протоколе WebDAV.

509 Bandwidth Limit Exceeded — Пропускная возможность канала исчерпана.

Данный код статуса, используется в случае превышения веб площадкой, отведенного ей лимита, на потребляемый трафик. Данный код не описан ни одним RFC и используется только модулем bw/limited, панели веб-хостинга cPanel.

510 Not Extended — Нет расширения.

У сервера отсутствует расширение, которое пытается использовать клиентом. Сервер может передавать информацию, об имеющихся у него расширениях. Введено в RFC 2774 для дополнения протокола HTTPподдержкой расширений.

Методы обработки запросов HTTP

HTTP метод — это основная операция, которую необходимо выполнить над ресурсом. В названии могут использоваться любые символы, кроме управляющих последовательностей и разделителей, как правило это короткое слово на английском языке. Имена методов HTTP зависимы от регистра.

Любой веб сервер обязан работать, по крайней мере с двумя методами GET и HEAD. Если сервер не смог определить метод, указанный в заголовке запроса клиента, он должен вернуть код статуса 501 (Not Implemented), если-же метод серверу известен, но неприменим к данному ресурсу, будет возвращен код статуса 405 (Method Not Allowed). Как в первом, так и во втором случае, сервер должен включить в свой ответ, заголовок Allow со списком методов, которые он поддерживает.

Метод OPTIONS

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

Что-бы выяснить возможности сервера, клиент должен указать в запросе URI, символ — «*«, то есть данный запрос к серверу выглядит как: OPTIONS * HTTP/1.1. Кроме прочего, данный запрос может быть использован для проверки работоспособности сервера и поддержки им протокола HTTP, версии 1.1. Результаты данного запроса не кэшируются.

Метод GET

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

Параметры для выполнения запроса, передаются в URI запрашиваемого ресурса, после символа «?«. Запрос в таком случае выглядит примерно так: GET /some/resource?param1=val1&param2=val2 HTTP/1.1.

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

Кроме вышесказанного, существуют еще два вида метода GET, это:
условный GET, содержащий заголовки If-Modified-Since, If-Match, If-Range и им подобные,
Частичный GET, содержащий заголовок Range с указанием байтового диапазона данных, которые сервер должен отдать. Данный вид запроса используется для докачки и организации многопоточных закачек.

Порядок работы с этими подвидами запроса GET, стандартами определен отдельно.

Метод HEAD

Данный метод, аналогичен методу GET, с той лишь разницей, что сервер не отправляет тело ответа. Метод HEAD, как правило используется для получения метаданных ресурса, проверки URL ( есть-ли указанный ресурс на самом деле ) и для выяснения факта изменения ресурса с момента последнего обращения к нему.

Заголовки ответа могут быть закэшированы, при несоответствии метаданных и информации в кэше, копия ресурса помечается как устаревшая.

Метод POST

Метод POST, используется для передачи пользовательских данных на сервер, указанному ресурсу. Примером может послужить HTML форма с указанным атрибутом Method=»POST», для отправки комментария к статье. После заполнения необходимых полей формы, пользователь жмет кнопку «Отправить» и данные, методом POST, передаются серверному сценарию, который в свою очередь выводит их на странице комментариев. Таким-же образом, с помощью метода POST, можно передавать файлы.

В отличии от GET, метод POST, не является идемпотентным, то есть неоднократное повторение запроса POST, может выдавать разные результаты. В нашем случае, будет появляться новая копия комментария при каждом запросе.

Если в результате запроса методом POST, возвращается код 200 (Ok) или 204 (No Content), в тело ответа сервера, добавляется сообщение о результате выполнения запроса. Например, если был создан ресурс, сервер вернет 201 (Created), указав при этом URI созданного ресурса в заголовке Location.

Ответы сервера, на выполнение метода POST, не кэшируются.

Метод PUT

Используется для загрузки данных запроса на указанный URI. В случае отсутствия ресурса по указанному в заголовке URI, сервер создает его и возвращает код статуса 201 (Created), если ресурс присутствовал и был изменен в результате запроса PUT, выдается код статуса 200 (Ok) или 204 (No Content). Если какой-то из переданных серверу заголовков Content-*, не опознан или не может быть использован в данной ситуации, сервер возвращает статус ошибки 501 (Not Implemented).

Главное различие методов PUT и POST в том, что при методе POST, предполагается, что по указанному URI, будет производиться обработка, передаваемых клиентом данных, а при методе PUT, клиент подразумевает, что загружаемые данные уже соответствуют ресурсу, расположенному по данному URI.

Ответы сервера при методе PUT не кэшируются.

Метод PATCH

Работает аналогично методу PUT, но применяется только к определенному фрагменту ресурса.

Метод DELETE

Удаляет ресурс, расположенный по заданному URI.

Метод TRACE

При запросе методом TRACE, клиент может увидеть, какие изменения были сделаны в запросе, промежуточными серверами.

Метод LINK

Связывает указанный ресурс с другим ресурсом.

Метод UNLINK

Снимает привязку одного ресурса к другому.

В прикладном смысле сайт — это набор файлов. Файлы каждого сайта находятся на том или ином физическом сервере. Чтобы пользователь мог перейти на нужный ресурс в интернете, нужно запросить эти файлы у сервера.

Сразу после того, как пользователь вбивает какой-то запрос в поисковик, браузер делает запрос на сервер. После этого сервер дает ответ и искомый сайт открывается в браузере. Однако иногда вместо ответа на запрос появляется ошибка.

Каждая ошибка имеет свой код. По коду можно определить возможные причины её появления. Рассмотрим, что означают ошибки 406, 410 и 505, из-за чего они появляются и как их можно исправить.

Ошибка 406 Not Acceptable

Если веб-сервер выдаёт код ошибки 406, значит запрос был заблокирован брандмауэром веб-приложений (WAF) ModSecurity. Брандмауэр ModSecurity — это программное обеспечение для веб-сервера Apache, которое фильтрует все поступающие к сайту запросы (веб-трафик). Он принимает корректные запросы и блокирует нежелательные. Например, защищает веб-ресурс от нелегитимных запросов, с помощью которых можно найти уязвимости CMS и затем взломать её.

ModSecurity по умолчанию подключают все хостинг-провайдеры для защиты сайтов клиентов. Подробнее о работе брандмауэра ModSecurity читайте на modsecurity.org.

HTTP 406 ошибка чаще всего имеет локальный характер и возникает на стороне клиента. В редких случаях, чтобы исправить проблему, необходимы действия со стороны владельца.

Основные причины

1. Брандмауэр ошибочно блокирует корректные запросы.
2. Временная проблема идентификации IP-адреса при подключении к Wi-Fi.
3. Ваш браузер поврежден вирусами. К заражению могли привести установленные для браузера расширения или поврежденные файлы операционной системы.
4. Поврежден реестр Windows. Нередко такое происходит в результате последних обновлений программного обеспечения или после удаления тех или иных его компонентов.
5. Когда клиенты жалуются, что видят страницу с 406, самая вероятная причина — некорректная работа плагинов CMS. Чаще всего такое бывает на Wordpress-сайтах.

Как исправить HTTP 406 Not Acceptable

Если вы пользователь:

1. Почистите файлы cookies. Если при повторном подключении вы снова увидите ошибку, попробуйте очистить кэш браузера. Возможно, доступ уже восстановлен, но ваш браузер обращается к старой версии страницы.
2. Отключите дополнительные расширения. Запустите браузер в режиме «Инкогнито». В этом режиме браузер задействует только базовые настройки. Если веб-ресурс доступен в этом режиме, значит причина ошибки в одном из дополнительных расширений, которые вы используете.
3. Переустановите браузер. Если вы отключили расширения, но доступ к сайту не появился, попробуйте ввести аналогичный запрос через другой поисковик. Если страница открывается, значит есть критические нарушения в работе текущего браузера.
4. Обновите драйверы компьютера. Иногда драйверы устройства отключаются и перестают автоматически работать. Это может спровоцировать нарушение в подключении. Для восстановления работы достаточно обновить драйверы.
5. Отмените последние изменения, если у вас Windows. Восстановление системы позволит вернуть программы и системные файлы вашего компьютера в то состояние, когда не было сбоев в работе.
6. Просканируйте системные файлы. Благодаря этому можно обнаружить поврежденные файлы и восстановить их. Это поможет оптимизировать работу компьютера и, возможно, устранить проблему.

Если указанные способы не помогли, вероятно, проблема связана с настройками сайта.

Если вы владелец сайта:

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

Если вы уверены, что на работу влияет конкретный плагин — отключите его. Если не уверены, то отключайте плагины по очереди, пока не вычислите нужный. Для этого:

2) Если ваш сайт создан не на WordPress или отключение плагинов не дало результата, чтобы исправить ошибку 406, напишите заявку в техническую поддержку.

Ошибка 410 Gone

Иногда при переходе на одну из страниц сайта может встретится ошибка 410, что значит, что этой страницы больше не существует. Следовательно, проблема возникла на стороне владельца сайта.

Этим 410 похожа на ошибку 404 (страница не найдена). Их основное отличие в том, что при ошибке 404 страница либо не существовала, либо наоборот — существует, но временно не найдена (например, потому что скрыта от пользователей). Ошибка 410 же сообщает, что страница точно существовала раньше, но затем её удалили.

Также ошибки по-разному обрабатывают поисковые роботы. Если роботы встретят страницу с ошибкой 404, они перенесут индексацию сайта на 24 часа. Если сервер выдаст страницу с 410, роботы сразу отметят её как удаленную и больше не будут индексировать. Для владельца сайта это не очень хороший сценарий, поскольку не индексируемые страницы негативно влияют на позиции сайта в поисковых системах.

Как исправить

Способ исправить ошибку 410 HTTP зависит от намерений владельца.

1. Если страница удалена по ошибке, можно попробовать восстановить её из резервной копии.
2. Если страницу удалили намеренно, лучше всего настроить редирект. Редирект помогает сделать перенаправление одной страницы на другую. Это позволит сохранить поисковые позиции.

Ошибка 505 HTTP Version Not Supported

Код ошибки 505 говорит нам о том, что проблема возникла на уровне сервера. Вот что означает ошибка 505: с её помощью сервер сообщает, что не может установить соединение по той версии HTTP-протокола, с помощью которой к нему хотят подключиться.

Основные причины

1. Пользователь использует устаревший браузер, который не поддерживает новые версии протокола. То есть в этом случае браузер подключается по версии HTTP 1.1, а сервер работает по версии HTTP 2.
2. Сервер не поддерживает HTTP-протокол, с помощью которого пытается подключиться клиент. Например, он работает по версии HTTP 1.1, а запрос поступает из браузера с версии HTTP 2.
3. Неверные директивы, указанные в файле .htaccess.
4. Неполадки в работе скриптов ресурса.

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

Если вы пользователь:

1. Почистите файлы cookies и кэш браузера.
2. Обновите версию браузера.
3. Обновите операционную систему и драйверы.
4. Обратитесь к интернет-провайдеру. Если все страницы показывают 505 в любых браузерах, обратитесь в службу поддержки вашего провайдера.

Если вы владелец сайта:

1. Узнайте, по какой версии протокола работает ваш сайт. Обновите её до актуальной, если необходимо. Например, серверы REG.RU работают с протоколом HTTP 1.1.
2. Проверьте логи веб-сервера. Определите, где кроется ошибка (в работе CGI-скриптов, директивах .htaccess или файле конфигурации веб-сервера) и исправьте её.
3. Если проблема в скриптах, обратитесь к разработчику сайта.

Здравствуйте.

Ситуация следующая. Собрал конфигурацию из базовых подсистем БСП, дописал свои объекты, создал Web-сервис, при первой публикации Web-сервис работал без ошибок, потребовалось внести незначительные изменения, стал выдавать ошибку:

Код состояния HTTP — это часть строки заголовка, ответа веб сервера на запрос клиента, информирующая о результате запроса и о том, что клиент должен предпринять далее

Код состояния HTTP — это часть строки заголовка, ответа веб сервера на запрос клиента, информирующая о результате запроса и о том, что клиент должен предпринять далее. Думаю не все знают как выглядит заголовок ответа сервера, зато уверен, каждый, пользующийся интернетом, не раз сталкивались, со страницей 404 Not Found или 403 Forbadden. Это и есть, видимый пользователю результат, выдачи сервером, того или иного кода статуса в строке заголовке.

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

1xx: Information — информационные

100 Continue — Продолжать.

Сервер доволен данными в запросе клиента, можно продолжать передачу заголовков. Появился в протоколе версии HTTP/1.1.

101 Switching Protocols — Переключение протоколов.

Сервер предлагает выбрать другой протокол, более соответствующий данному ресурсу. Протоколы предлагаемый сервером, указываются в строке заголовка Update, если предложенный сервером протокол, устраивает клиента, он высылает новый запрос с указанием нового протокола. Появился в протоколе версии HTTP/1.1.

102 Processing — Обрабатывается.

Используется в протоколе WebDAV, работающем поверх HTTP протокола. Данный код статуса информирует клиента о том, что запрос принят, но на его обработку может понадобится определенное время, что-бы он ( клиент ), не сбрасывал соединение. Клиент в этом случае должен обнулить таймер и ожидать следующей команды.

2xx: Success — Успешное завершение

200 OK — Хорошо.

Запрос к ресурсу выполнен успешно. Данные, запрошенные клиентом, находятся в заголовке и/или в теле ответа. Появился в протоколе версии HTTP/1.0.

201 Created — Создано.

Запрос выполнен успешно, новый ресурс создан. В ответе сервера, в заголовке Location, указывается местоположение созданного ресурса. Кроме того, серверу рекомендуется указывать характеристики созданного ресурса, в заголовке ответа. Появился в протоколе версии HTTP/1.0.

202 Accepted — Принято.

Запрос принят, но еще в обработке. Появился в протоколе версии HTTP/1.0.

203 Non-Authoritative Information — Информация из неавторитетного источника.

Аналогично коду 200, но в данном случае информация может быть неактуальной, так как взята не из первоисточника. Появился в протоколе версии HTTP/1.1.

204 No Content — Отсутствует содержимое.

Сервер успешно обработал запрос, но не вернул содержимого. Появился в протоколе версии HTTP/1.0.

205 Reset Content — Сбросить содержимое.

Сервер успешно обработал запрос, но не вернул содержимого. В отличии от кода 204, данный код, требует от клиента, сбросить представление документа. Появился в протоколе версии HTTP/1.1.

206 Partial Content — Часть содержимого.

Сервер вернул результат запроса клиентом, части содержимого, с помощью заголовка range. Используется для докачки файлов или для многопоточной закачки. Появился в протоколе версии HTTP/1.1.

207 Multi-Status — Многостатусный.

Возвращаемое сервером тело сообщения, представляет из себя XML документ со статусами выполнения нескольких подзапросов. Используется в протоколе WebDAV.

226 IM Used — Использовано IM

Расширение HTTP для поддержки «дельта кодирования» ( delta encoding ). Заголовок A-IM принят, данные возвращаются согласно установленным параметрам.

3xx: Redirection — Редирект ( перенаправление )

Коды данной категории, сообщают клиенту, что для завершения запроса, ему необходимо выполнить дополнительный запрос, как правило по другому URI, соответствующий адрес указывается в строке Location, ответа сервера. Программа — клиент может совершать дополнительные запросы без участия пользователя, при условии что дополнительный запрос делается методами GET или HEAD.

Некоторые клиенты некорректно работают с редиректами 301 и 302, применяя в запросе ко второму ресурсу метод GET, несмотря на то, что первый запрос был сделан с использованием другого метода. В протоколеHTTP версии 1.1, вместо ответа статуса 302, были введены дополнительные коды ответов, 303 и 307. Изменять метод, необходимо только в случает ответа сервера со статусом 303, в остальных случаях использовать исходный метод.

300 Multiple Choices — Несколько вариантов выбора.

По запрошенному URI, существует несколько вариантов ресурса, различных по MIME типу. языку или другим признакам. В ответе сервера, передается список альтернатив, выбираемый клиентским приложением автоматически или самим пользователем. Появился в протоколе версии HTTP/1.0.

301 Moved Permanently — Перемещёно окончательно.

Запрошенный ресурс был окончательно перемещен на URI, указанный в строке заголовка Location, ответа сервера. Некоторые клиенты, при обработке данного кода, ведут себя некорректно, см. выше. Появился в протоколе версии HTTP/1.0.

302 Found — Найдено ( Moved Temporarily )

Данный код статуса сообщает клиенту, что ресурс временно доступен по другому URI, указанному в строке заголовка Location, заголовка ответа сервера. Данный код используется например, при согласовании содержимого ( Content Negotiation ), выполняемого сервером. Появился в протоколе версии HTTP/1.0.

303 See Other — Смотреть другое.

Документ из запрошенного URI, нужно запросить по адресу, указанному в строке заголовка Location, заголовка ответа сервера, используя метод GET, невзирая на то, каким методом был сделан первый запрос. Появился в протоколе версии HTTP/1.1.

304 Not Modified — Не изменялось.

Данный код выдается в случае запроса документа, методом GET, с использованием заголовков If-Modified-Since или If-None-Match, и документ не был изменен с указанного момента времени. Появился в протоколе версии HTTP/1.0.

305 Use Proxy — Использовать прокси сервер.

Запрос к ресурсу, должен выполняться через прокси-сервер., адрес которого, указан в строке заголовка Location, заголовка ответа сервера. Появился в протоколе версии HTTP/1.1.

307 Temporary Redirect — Временное перенаправление

Запрошенный ресурс временно доступен по URI, указанному в строке заголовка Location, заголовка ответа сервера. Появился в протоколе версии HTTP/1.1.

4xx: Client Error — Ошибка клиента

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

400 Bad Request — Плохой запрос.

Из-за синтаксической ошибки, запрос не был понят сервером. Появился в протоколе версии HTTP/1.0.

401 Unauthorized — Не авторизован.

Ресурс требует идентификации пользователя. Клиентское приложение запрашивает у пользователя данные для аутентификации ( имя, пароль ) и передает их на сервер в заголовке WWW-Authenticate. Если данные указаны не правильно, будет снова выдан этот-же код статуса. Появился в протоколе версии HTTP/1.0.

402 Payment Required — Необходима оплата.

Пока не используется. Появился в протоколе версии HTTP/1.1.

403 Forbidden — Запрещено.

Сервер отказал в доступе к запрошенному ресурсу ввиду ограничений. Ограничения могут быть любыми, установленными администратором сервера, или определенным веб приложением. Например, в целях безопасности, закрыт доступ к файлу, .htacces или .htpasswd или к закрытой директории сайта, или в случае, когда аутентификация должна производится через веб приложение ( например сайтовый движок ), ну или блокировка по IP адресу, в случае слишком частых обращений. Появился в протоколе версии HTTP/1.0.

404 Not Found — Не найдено.

Сервер не нашел запрошенный ресурс по указанному адресу. Кроме того данный код ответа можно использовать вместо 403, с целью, скрыть расположение документа, доступ к которому запрещен. Появился в протоколе версии HTTP/1.0.

405 Method Not Allowed — Метод не поддерживается.

Клиент попытался использовать метод, недопустимый для данного ресурса. Сервер передает в заголовке, строку Allow, содержащую список допустимых методов. Появился в протоколе версии HTTP/1.1.

406 Not Acceptable — Не приемлемо.

Запрошенный ресурс, не удовлетворяет, запрошенные характеристики. В случае, если запрос был сделан не методом HEAD, сервер вернет список допустимых характеристик запрошенного ресурса. Появился в протоколе версии HTTP/1.1.

407 Proxy Authentication Required — Необходима прокси авторизация.

Данный код статуса, аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Появился в протоколе версии HTTP/1.1.

408 Request Timeout — Время ожидания истекло.

Истек таймаут ожидания передачи данных, между сервером и клиентом. Появился в протоколе версии HTTP/1.1.

409 Conflict — Конфликт.

Конфликтная ситуация при обращении к ресурсу. Такое может произойти, например, при попытке одновременного изменения файла, методом PUT, несколькими клиентами. Появился в протоколе версииHTTP/1.1.

410 Gone — Удалён.

Данный ответ выдается в случае, если документ был по указанному URI, но в данный момент удален. Появился в протоколе версии HTTP/1.1.

411 Length Required — Необходима длина.

Этот код статуса говорит о том, что для данного URI, в заголовке запроса, должно быть указано значение в поле Content-Length. Появился в протоколе версии HTTP/1.1.

412 Precondition Failed — Условие «ложно.

Данный код выдается в случае, если ни одно из условных полей заголовка не было удовлетворено. Появился в протоколе версии HTTP/1.1.

413 Request Entity Too Large — Запрошены слишком большие данные.

Данный код выдается, если сервер по каким-либо причинам, не может передать, требуемый объем данных. Если это временная проблема, сервер может указать время, по истечении которого можно будет попробовать повторно запросить ресурс, в строке заголовка, Retry-After. Появился в протоколе версии HTTP/1.1.

414 Request-URI Too Long — Запрашиваемый URI слишком длинный.

Слишком длинная строка запроса. Такая ситуация может произойти, например в случае попытки, передать данные методом GET, вместо использования POST. Появился в протоколе версии HTTP/1.1.

415 Unsupported Media Type — Неподдерживаемый тип данных.

Сервер, по какой-то причине, отказался обрабатывать запрошенные данные, используемым методом. Появился в протоколе версии HTTP/1.1.

416 Requested Range Not Satisfiable — Запрашиваемый диапазон не достижим.

В строке заголовка запроса Range, установлен диапазон, выходящий за рамки запрошенного ресурса и отсутствует строка If-Range. Появился в протоколе версии HTTP/1.1.

417 Expectation Failed — Ожидаемое не приемлемо.

Сервер не может обработать строку заголовка запроса Expect. Появился в протоколе версии HTTP/1.1.

422 Unprocessable Entity — Необрабатываемый экземпляр.

Запрос принят, тип данных может быть обработан, синтаксис XML данных в теле запроса верен, но имеет место логическая ошибка, не позволяющая обработать запрос к ресурсу. Используется в протоколеWebDAV.

423 Locked — Заблокировано.

Запрошенный ресурс заблокирован от данного метода. Используется в протоколе WebDAV.

424 Failed Dependency — Невыполненная зависимость.

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

425 Unordered Collection — Беспорядочный набор.

Этот код статуса будет выдан в случае, если клиент отправил запрос обозначив положение в неотсортированной коллекции или используя порядок следования элементов отличный от серверного. Введено в черновике по WebDAV Advanced Collections Protocol.

426 Upgrade Required — Требуется обновление.

Указание сервера, клиенту, обновить протокол. Заголовок ответа, должен содержать правильно составленные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредствомHTTP.

449 Retry With — Повторить с…

Выдается в случае поступления не достаточного количества информации для обработки запроса. В заголовок ответа сервера, помещается строка Ms-Echo-Request. Введено корпорацией Microsoft дляWebDAV.

5xx: Server Error — Ошибка на стороне сервера

Коды данной категории, предназначены для ситуаций, когда обработка запроса не возможна по вине сервера. Во всех случаях, кроме использования метода HEAD, сервер должен включать в тело ответа, объяснение для пользователя.

500 Internal Server Error — Внутренняя ошибка сервера.

Любая внутренняя ошибка на стороне сервера не подпадающая под остальные ошибки из категории 5хх. Появился в протоколе версии HTTP/1.0.

501 Not Implemented — Не реализовано.

Сервер не поддерживает, необходимых для обработки запроса, возможностей. ( например не поддерживается необходимый метод обработки ). Появился в протоколе версии HTTP/1.0.

502 Bad Gateway — Плохой шлюз.

Сервер, работающий в качестве прокси или шлюза, получил сообщение о неудачное в промежуточной операции. Появился в протоколе версии HTTP/1.0.

503 Service Unavailable — Сервис недоступен.

Сервер не в состоянии обрабатывать запросы клиентов по техническим причинам. Появился в протоколе версии HTTP/1.0.

504 Gateway Timeout — Истек таймаут ожидания ответа шлюза.

Проксирующий сервер или шлюз, не дождался ответа от вышестоящего сервера для завершения обработки запроса. Появился в протоколе версии HTTP/1.0.

505 HTTP Version Not Supported — Версия HTTP протокола не поддерживается.

Сервер не поддерживает, или не может обработать, указанную в заголовке версию HTTP протокола. Появился в протоколе версии HTTP/1.0.

506 Variant Also Negotiates — Вариант тоже согласован.

Из-за не верной конфигурации, выбранный вариант указывает сам на себя, в следствии чего, связывание прерывается. Добавлено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

507 Insufficient Storage — Переполнение хранилища.

Недостаточно места для обработки текущего запроса. Возможно временная проблема. Используется в протоколе WebDAV.

509 Bandwidth Limit Exceeded — Пропускная возможность канала исчерпана.

Данный код статуса, используется в случае превышения веб площадкой, отведенного ей лимита, на потребляемый трафик. Данный код не описан ни одним RFC и используется только модулем bw/limited, панели веб-хостинга cPanel.

510 Not Extended — Нет расширения.

У сервера отсутствует расширение, которое пытается использовать клиентом. Сервер может передавать информацию, об имеющихся у него расширениях. Введено в RFC 2774 для дополнения протокола HTTPподдержкой расширений.

Методы обработки запросов HTTP

HTTP метод — это основная операция, которую необходимо выполнить над ресурсом. В названии могут использоваться любые символы, кроме управляющих последовательностей и разделителей, как правило это короткое слово на английском языке. Имена методов HTTP зависимы от регистра.

Любой веб сервер обязан работать, по крайней мере с двумя методами GET и HEAD. Если сервер не смог определить метод, указанный в заголовке запроса клиента, он должен вернуть код статуса 501 (Not Implemented), если-же метод серверу известен, но неприменим к данному ресурсу, будет возвращен код статуса 405 (Method Not Allowed). Как в первом, так и во втором случае, сервер должен включить в свой ответ, заголовок Allow со списком методов, которые он поддерживает.

Метод OPTIONS

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

Что-бы выяснить возможности сервера, клиент должен указать в запросе URI, символ — «*«, то есть данный запрос к серверу выглядит как: OPTIONS * HTTP/1.1. Кроме прочего, данный запрос может быть использован для проверки работоспособности сервера и поддержки им протокола HTTP, версии 1.1. Результаты данного запроса не кэшируются.

Метод GET

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

Параметры для выполнения запроса, передаются в URI запрашиваемого ресурса, после символа «?«. Запрос в таком случае выглядит примерно так: GET /some/resource?param1=val1&param2=val2 HTTP/1.1.

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

Кроме вышесказанного, существуют еще два вида метода GET, это:
условный GET, содержащий заголовки If-Modified-Since, If-Match, If-Range и им подобные,
Частичный GET, содержащий заголовок Range с указанием байтового диапазона данных, которые сервер должен отдать. Данный вид запроса используется для докачки и организации многопоточных закачек.

Порядок работы с этими подвидами запроса GET, стандартами определен отдельно.

Метод HEAD

Данный метод, аналогичен методу GET, с той лишь разницей, что сервер не отправляет тело ответа. Метод HEAD, как правило используется для получения метаданных ресурса, проверки URL ( есть-ли указанный ресурс на самом деле ) и для выяснения факта изменения ресурса с момента последнего обращения к нему.

Заголовки ответа могут быть закэшированы, при несоответствии метаданных и информации в кэше, копия ресурса помечается как устаревшая.

Метод POST

Метод POST, используется для передачи пользовательских данных на сервер, указанному ресурсу. Примером может послужить HTML форма с указанным атрибутом Method=»POST», для отправки комментария к статье. После заполнения необходимых полей формы, пользователь жмет кнопку «Отправить» и данные, методом POST, передаются серверному сценарию, который в свою очередь выводит их на странице комментариев. Таким-же образом, с помощью метода POST, можно передавать файлы.

В отличии от GET, метод POST, не является идемпотентным, то есть неоднократное повторение запроса POST, может выдавать разные результаты. В нашем случае, будет появляться новая копия комментария при каждом запросе.

Если в результате запроса методом POST, возвращается код 200 (Ok) или 204 (No Content), в тело ответа сервера, добавляется сообщение о результате выполнения запроса. Например, если был создан ресурс, сервер вернет 201 (Created), указав при этом URI созданного ресурса в заголовке Location.

Ответы сервера, на выполнение метода POST, не кэшируются.

Метод PUT

Используется для загрузки данных запроса на указанный URI. В случае отсутствия ресурса по указанному в заголовке URI, сервер создает его и возвращает код статуса 201 (Created), если ресурс присутствовал и был изменен в результате запроса PUT, выдается код статуса 200 (Ok) или 204 (No Content). Если какой-то из переданных серверу заголовков Content-*, не опознан или не может быть использован в данной ситуации, сервер возвращает статус ошибки 501 (Not Implemented).

Главное различие методов PUT и POST в том, что при методе POST, предполагается, что по указанному URI, будет производиться обработка, передаваемых клиентом данных, а при методе PUT, клиент подразумевает, что загружаемые данные уже соответствуют ресурсу, расположенному по данному URI.

Ответы сервера при методе PUT не кэшируются.

Метод PATCH

Работает аналогично методу PUT, но применяется только к определенному фрагменту ресурса.

Метод DELETE

Удаляет ресурс, расположенный по заданному URI.

Метод TRACE

При запросе методом TRACE, клиент может увидеть, какие изменения были сделаны в запросе, промежуточными серверами.

Метод LINK

Связывает указанный ресурс с другим ресурсом.

Метод UNLINK

Снимает привязку одного ресурса к другому.

Server and client-side errors happen occasionally, and we commonly refer to them as HTTP responses or status codes. The “406 error” or “406 Not Acceptable” error is one such HTTP response.

You may see the 406 error while visiting a site. Or worse, on your website. While It may irritate the average internet user, it can be borderline terrifying for a website or application owner. Besides looking somewhat unprofessional and confusing, any HTTP response code, including the 406 error, can lose sales and users.

This article will explain the basics of the “406 Not Acceptable” error, its causes, how to fix it, and steps to avoid it in the future.

Check Out Our Guide to Fixing a 406 Error and Find the Source of the Problem

What Is 406 Error?

The good news is that the HTTP error “406 Not Acceptable” message is not nearly as common as the 404 server error (which usually indicates a non-existent webpage), or even 301 or 500 HTTP errors. Therefore, you definitely shouldn’t see this one as much.

Although it’s rare, it’s still possible that the 406 error may come into play as a problem for your website. It usually looks like this:

The message typically reads:

Not Acceptable

An appropriate representation of the requested resource could not be found on this server.

It then sometimes identifies the “requested resource” where the problem lies, with other messages or server information mentioned at the end:

The appearance and text within the 406 error message depending on the website, host, and browser used to access the website. The 406 error may reveal where the errors stem from. Other times you may find that it’s a simple “406 Not Acceptable” error without any information helping you solve the problem.

Now, let’s pretend browsers spoke in plain English and not these cryptic messages. In that case, the browser would be saying something like this:

Hello, I’m a browser. I tried to show this webpage, but one of the two problems occurred:

1. The website’s server sent me the wrong file format, so I can’t accept it.
2. The website’s server violates some settings or security requirements.

Therefore, please resolve the violation or have the server use one of the file formats I accept. In case you’re wondering, here are the file formats I know how to read.

If only browsers were that friendly!

Essentially, there’s a miscommunication between the server and the browser or machine used to present the web application. The browser either can’t read what’s coming in or verify the data because it didn’t meet some requirements.

Now we have to answer some questions to figure out the cause of that miscommunication.

Server and client-side errors happen from time to time, but that doesn’t make them any less frustrating 😅 Learn how to fix one common error in this in-depth guide 👇Click to Tweet

What Causes the 406 Error?

Every time you open a web page, your browser (like Safari, Firefox, Brave, Chrome, or Internet Explorer) sends a request to the page’s server to obtain site content and database files. The browser acts as the messenger between you and the server — it tells the server what the user wants to see, and hopefully, the correct information comes back.

During that first request, the browser tells the server all about the file formats it can accept. It’s called an Accept- header request, which prompts the server to deliver the files in the proper formats to produce the entire website or web application, starting with the header.

Sometimes the server sends a reply that’s not in the suitable format or violates a rule set forth by the browser or client machine. In this situation, a 406 error appears in the browser window, indicating the server isn’t delivering the appropriate data.

Here are some examples of “bad formats” and “rule violations” that can come up with the header requests:

• Accept-ranges: Some servers have security measures set in place or only allow a specific file size range in the response. If the response attempts to send too many bytes outside the allowable range, you’ll see the 406 error.
• Accept-encoding: Here’s an area of the header meant to compress files, so they move quickly from the server to the browser. Some compression methods and formats aren’t accepted, rendering a 406 error code.
• Accept-charset: Refers to a character set or how site file tables take code (like CSS and HTML) and turn it into understandable characters. There are so many characters, languages, and symbols in the world that it’s challenging to cover them all. The standard table is called ISO-8859, but there are other complementary tables as well. New character tables occasionally get released to keep up with language and character additions.
• Accept-language: This is usually a different name for Accept-charset that references its focus on international languages.
• MIME type violation: Sometimes, the browser requests a specific MIME type from the server. MIME types are content elements like JPEG images, specific video formats, or simple text. If the server can’t provide a requested MIME type, like JPEG images, you’ll see a 406 error.

The primary way to address and fix a 406 error is by checking the source code for issues in the Accept-, Request-, and Response- headers.

The easiest way to review Accept- and Response- headers is to open a webpage in your browser, right-click, and select Inspect.

Go to Network > Headers to reveal all requests from this webpage.

You can typically select any request from the long list to see the Request- and Response- headers for that particular request.

Or, you can contact your web developer to take a look into the source code. However, checking the source code is much easier when you have tools for debugging and cleaning your database, which we’ll discuss later in this article.

As mentioned before, a “406 Not Acceptable” error tells us that the client has sent a valid request to the server, but the request included a unique requirement for the server to follow. That special requirement in the initial request was in the form of an HTTP Accept- header.

That leaves us with a few potential causes:

1. The server didn’t provide the requested MIME type or proper formats, like a JPEG or mp4 video.
2. The server didn’t return with the correct language (Accept-language). For instance, it may have sent back a response in German when the browser asked for French.
3. The server used the wrong compression method or format in response to the Accept-encoding request.
4. The server sent back too many bytes that didn’t align with the Accept-ranges request.
5. The server failed to provide understandable characters, which would result in a problem with the Accept-charset request from the browser.

There are other reasons you may see the 406 error, but they’re not nearly as common. The above list is from the most common reasons to the least common. The first two come into play far more often than the others, so there’s a good chance you should usually focus on troubleshooting the potential for a MIME type violation or an Accept-language problem.

Overall, website owners should know about these format problems and violations, seeing how something within your site files may cause problems. Such situations often occur because of human error, like accidentally typing in the wrong code, deleting necessary code, or misconfiguring the server. The 406 error also appears when specific security settings or rules block content transmission from the server.

How to Fix the 406 Error

It’s prudent to run a website or application backup before completing any steps to resolve a 406 error. There’s always the potential for causing further problems by going into your site’s source code, so you’ll want to have a database and site file backup to restore if necessary.

Make sure you complete a full backup with everything from the database to the application and the media elements to the site files. If you’re a Kinsta user, you can do this with the MyKinsta backup feature, which logs your entire website in a separate file and has a Restore button for later use:

Now that we have a deeper understanding of why the 406 error occurs, it’s time to talk about the best methods to troubleshoot the error and prevent it from happening again.

These tactics include client-side causes (where a user makes an error or the machine isn’t working correctly), server-side causes, and platform-based causes like faulty plugins.

Make Sure the URL Is Correct

Our first piece of advice may sound simple, but it’s the quickest troubleshooting option, and it puts a focus on issues with the client-side of things (i.e., your computer).

A 404 error is far more likely than a 406 error in this situation, but you may end up seeing a “406 Not Acceptable” error if the website URL is valid. Yet, there’s something odd about the way your browser translates the request. For instance, adding “JSON” or “PHP” to the end of URLs could be misinterpreted as a request for those particular formats, even though the client doesn’t need them.

To resolve the issue, double-check the previously used URL that produced the error. Try typing it in again or opting for a different subdomain on the website to see if it’s only one page that isn’t rendering.

A 406 message is technically considered a client-side error code (even though it’s often a platform or server issue), so this is the first course of action to determine if something’s wrong on the client side.

Reset Your Devices and Networks

Another client-side problem occasionally involves those same Accept- headers sent from the user’s computer to a platform that can’t satisfy the request. Many of these platforms include gaming- or media-oriented systems like Hulu or music marketplaces like Spotify.

In simpler terms, you may log into a platform like Hulu, try to watch your favorite TV show, and receive a 406 error message. In this example, the problem is almost always on the client-side. It’s usually your computer, network, or another device you’ve used to launch the platform.

Although it can happen with any platform, some platforms that commonly report 406 errors include:

• Hulu
• Google Play
• Square Enix Games
• Netflix
• Xbox
• Windows (usually for gaming)

This list is far from complete, but it gives you an idea of where the 406 error may occur.

Media and gaming platforms are complicated with many restrictions, and those restrictions depend on your location or network configuration. There’s a chance you might encounter an error like this due to all the moving pieces.

Although we can’t help you troubleshoot every specific platform, consider walking through the following recommendations and checking to see if the error resolves:

• Go online to check the status of your platform’s server. It may simply be a problem with the company’s server.
• Restart your computer, gaming system, streaming device, or other machines.
• Disconnect all devices from their cables, wait a few minutes before reconnecting them all, and check to see if the error is gone.
• Check if the app is running the most current version. Also, see if any of your machines have firmware updates available.
• Reset your home or office network (the WiFi or internet connection through your router).
• Consider switching from a wireless network to a wired network connection if you’re still having trouble.
• Although this isn’t always a possibility, consider duplicating the error with a completely different machine. Make sure that the device is on the same network. If you can’t replicate the error, look into your network and the original machine.

If all else fails, go to your search engine and type in the name of your platform along with “+ 406 error code” for platform-specific troubleshooting advice. That often reveals forums and support documentation to guide you through the process.

Rollback Your Recent CMS Changes

Next, it’s time to explore the system used for your websites or applications. You may find that your content management system, such as WordPress, is the direct cause of a “406 Not Acceptable” error due to a complication with something inside your site files.

Whether using WordPress or any other content management system, look into when your last update occurred. WordPress has a sturdy default infrastructure meant to avoid these types of errors, no matter what.

However, specific plugins, themes, or manually adjusted coding could produce situations where the site files violate client or server requests. A simple upgrade to your CMS’s latest version can solve the problem right away.

To figure out if it’s your CMS, start by rolling back any recent upgrades that occurred to the core files. As you may already know, WordPress sends out updates to its system regularly. Most of these updates happen automatically, but older versions still require you to click a button.

Furthermore, WordPress and other CMSs utilize several moving parts like plugins, themes, and extensions. Those also get updated regularly, so you might need to roll back some of them.

For all systems outside of WordPress, search for “platform name + how to downgrade.”

If you use WordPress, you can easily downgrade your WordPress website, effectively rolling it back to one of the previous versions:

That guide outlines the following methods for downgrading your WordPress site, most of which only take a few minutes:

• Manually downgrading your WordPress site.
• Using a plugin to complete the WordPress system downgrade.
• Restoring a previous backup to bring back an old version, or at least the content and files from before.
• Manually downgrading a theme or plugin.
• Downgrading a plugin or theme with a separate plugin.
• Switching to an older version of PHP.

Uninstall and Reinstall Plugins, Themes, and Extensions

WordPress plugins and themes add extra code to your site files that interact with the core WordPress files. Reputable plugins typically don’t cause any problems, but occasionally a conflict occurs. A plugin, theme, or third-party extension may be the reason for the 406 error.

The tried-and-true method for identifying a troublesome plugin or theme is to deactivate your plugins and themes one by one. After disabling each, check to see if the 406 error has vanished. If so, you’ve found the problem. If it doesn’t go away, reinstall the plugin or theme and continue uninstalling the next one.

Analyze the Status of Your Database for Changes and Conflicts

Unfortunately, a removed “problem” plugin could still affect your WordPress database since plugins get full access to the database to work well. Therefore, you should still check the status of your database even if it appears the removal of a plugin has made the 406 error go away. Otherwise, you may still run the risk of seeing further issues in the future.

If a plugin or theme wasn’t the culprit, you should also check your database if it’s the primary source of the error. Sometimes a database change, whether accidental or purposeful, becomes the primary reason a 406 error appears.

To scan and fix your database, consider these solutions:

1. Install a database scanner and cleaner that removes useless and troublesome tables and assets. Some options include WP Optimize and the Advanced Database Cleaner. Much of this process involves deleting old or orphaned items like trash posts, revisions, and metadata. It’s a solid first step to cleaning up your database and potentially eliminating that 406 error.
2. Scan the database and look for records and tables potentially changed by a problematic plugin or ones that look out of place or unnecessary.
3. If you have an idea of what’s wrong with your database, go to a search engine and seek out help from forums and other discussions online. There’s a good chance someone else has experienced the same problem.

Analyze Your Server Logs

The previous recommendations focus on client-side and CMS-oriented troubleshooting. Now we’ll consider all server-side issues. This tip, and the ones following, are best if you aren’t using a CMS or know that the 406 error has no connection to your CMS or client machine.

The first step in troubleshooting the server is checking the logs. It doesn’t matter what type of web application, CMS, or web design system you use; they all have server-side logs.

The application logs store that web application’s entire (or recent) history, with information about each database inquiry, results provided, pages requested, and much more. On the other hand, the server logs contain information about the health and status of the server or hardware used to run the web application.

For Kinsta users, you can find error and server logs in the MyKinsta dashboard. Check all logs that may be causing the 406 error:

• The error.log file
• The kinsta-cache-perf.log file
• The access.log file

You can also check raw access and WordPress error log files with an FTP client. Other options include enabling error logs in wp-config.php and going through the debug mode in the MyKinsta dashboard.

If you have problems finding the error logs or don’t know how to interpret them, contact the Kinsta customer support team for assistance.

Debug the Web Application (Like WordPress)

Like most web applications have server and error logs, they also typically provide information about debugging the application itself. Debugging involves going through the application’s code to find and eliminate minor errors (or bugs).

One of the best ways to run a complete scan of WordPress (and any web application for that matter) is to debug the database and website files. Luckily, debugging doesn’t mean you have to read through every line of code and pick out the bugs yourself. Programs are available for this specific purpose, and as we mentioned earlier, Kinsta even has its debugging tool within the MyKinsta dashboard.

Start the debugging process by learning the basics of debugging WordPress with the Kinsta Debug Mode, WordPress Debug plugins, or a more manual process:

Preventing the 406 Error in the Future

The problem with the 406 error is that it can pop up in many different situations. You might see the “406 Not Acceptable HTTP” error while browsing through Hulu or Netflix as a regular consumer.

That isn’t very pleasant, but nothing a little troubleshooting can’t fix. The more concerning occurrence of the 406 error is when it happens on your website or application. For those instances, you’ll need to check the server and CMS site files.

If it’s your website, you’ll want to prevent the error from ever happening again. Plugins, themes, and human error can always come into play, but we have a few suggestions to keep your databases and site files clean into the future:

• Only install necessary and reputable plugins, themes, and extensions. Always keep these elements to a minimum.
• Don’t ever modify the core WordPress files unless you absolutely must and know what you’re doing.
• Run a database cleaner and site optimizer regularly. We recommend completing this process every month and ideally finding a cleaner plugin that runs automatically in the background.
• Make a habit of debugging your server and web application. As mentioned, Kinsta offers a Debugging feature in its dashboard. Many other applications have this type of functionality as well.
• Set automated backups of your website or application. This way, a code conflict or error won’t cause you much stress since you can restore a previous version of the website and start from there.
• Run a manual backup of your site before you plan on updating WordPress and any plugins, even if you already run automated backups (better safe than sorry). It’s also wise to run backups before editing any files or adding new code to your site.

In addition to looking unprofessional and causing confusion, the 406 error can cause you to lose sales or users 💸 Learn how to fix it here ⬇️Click to Tweet

Summary

You can fix the 406 error in several ways. As long as you know what you are seeing and where to look for the fix, you should be able to clear the error up.

While this is not one of the more common WordPress errors, it is one you will see from time to time if your configuration is not correct.

Do you have any other recommendations for resolving “406 Not Acceptable” errors? Please share them in the comments section below!

В прикладном смысле сайт — это набор файлов. Файлы каждого сайта находятся на том или ином физическом сервере. Чтобы пользователь мог перейти на нужный ресурс в интернете, нужно запросить эти файлы у сервера.

Сразу после того, как пользователь вбивает какой-то запрос в поисковик, браузер делает запрос на сервер. После этого сервер дает ответ и искомый сайт открывается в браузере. Однако иногда вместо ответа на запрос появляется ошибка.

Каждая ошибка имеет свой код. По коду можно определить возможные причины её появления. Рассмотрим, что означают ошибки 406, 410 и 505, из-за чего они появляются и как их можно исправить.

Ошибка 406 Not Acceptable

Если веб-сервер выдаёт код ошибки 406, значит запрос был заблокирован брандмауэром веб-приложений (WAF) ModSecurity. Брандмауэр ModSecurity — это программное обеспечение для веб-сервера Apache, которое фильтрует все поступающие к сайту запросы (веб-трафик). Он принимает корректные запросы и блокирует нежелательные. Например, защищает веб-ресурс от нелегитимных запросов, с помощью которых можно найти уязвимости CMS и затем взломать её.

ModSecurity по умолчанию подключают все хостинг-провайдеры для защиты сайтов клиентов. Подробнее о работе брандмауэра ModSecurity читайте на modsecurity.org.

HTTP 406 ошибка чаще всего имеет локальный характер и возникает на стороне клиента. В редких случаях, чтобы исправить проблему, необходимы действия со стороны владельца.

Основные причины

1. Брандмауэр ошибочно блокирует корректные запросы.
2. Временная проблема идентификации IP-адреса при подключении к Wi-Fi.
3. Ваш браузер поврежден вирусами. К заражению могли привести установленные для браузера расширения или поврежденные файлы операционной системы.
4. Поврежден реестр Windows. Нередко такое происходит в результате последних обновлений программного обеспечения или после удаления тех или иных его компонентов.
5. Когда клиенты жалуются, что видят страницу с 406, самая вероятная причина — некорректная работа плагинов CMS. Чаще всего такое бывает на Wordpress-сайтах.

Как исправить HTTP 406 Not Acceptable

Если вы пользователь:

1. Почистите файлы cookies. Если при повторном подключении вы снова увидите ошибку, попробуйте очистить кэш браузера. Возможно, доступ уже восстановлен, но ваш браузер обращается к старой версии страницы.
2. Отключите дополнительные расширения. Запустите браузер в режиме «Инкогнито». В этом режиме браузер задействует только базовые настройки. Если веб-ресурс доступен в этом режиме, значит причина ошибки в одном из дополнительных расширений, которые вы используете.
3. Переустановите браузер. Если вы отключили расширения, но доступ к сайту не появился, попробуйте ввести аналогичный запрос через другой поисковик. Если страница открывается, значит есть критические нарушения в работе текущего браузера.
4. Обновите драйверы компьютера. Иногда драйверы устройства отключаются и перестают автоматически работать. Это может спровоцировать нарушение в подключении. Для восстановления работы достаточно обновить драйверы.
5. Отмените последние изменения, если у вас Windows. Восстановление системы позволит вернуть программы и системные файлы вашего компьютера в то состояние, когда не было сбоев в работе.
6. Просканируйте системные файлы. Благодаря этому можно обнаружить поврежденные файлы и восстановить их. Это поможет оптимизировать работу компьютера и, возможно, устранить проблему.

Если указанные способы не помогли, вероятно, проблема связана с настройками сайта.

Если вы владелец сайта:

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

Если вы уверены, что на работу влияет конкретный плагин — отключите его. Если не уверены, то отключайте плагины по очереди, пока не вычислите нужный. Для этого:

2) Если ваш сайт создан не на WordPress или отключение плагинов не дало результата, чтобы исправить ошибку 406, напишите заявку в техническую поддержку.

Ошибка 410 Gone

Иногда при переходе на одну из страниц сайта может встретится ошибка 410, что значит, что этой страницы больше не существует. Следовательно, проблема возникла на стороне владельца сайта.

Этим 410 похожа на ошибку 404 (страница не найдена). Их основное отличие в том, что при ошибке 404 страница либо не существовала, либо наоборот — существует, но временно не найдена (например, потому что скрыта от пользователей). Ошибка 410 же сообщает, что страница точно существовала раньше, но затем её удалили.

Также ошибки по-разному обрабатывают поисковые роботы. Если роботы встретят страницу с ошибкой 404, они перенесут индексацию сайта на 24 часа. Если сервер выдаст страницу с 410, роботы сразу отметят её как удаленную и больше не будут индексировать. Для владельца сайта это не очень хороший сценарий, поскольку не индексируемые страницы негативно влияют на позиции сайта в поисковых системах.

Как исправить

Способ исправить ошибку 410 HTTP зависит от намерений владельца.

1. Если страница удалена по ошибке, можно попробовать восстановить её из резервной копии.
2. Если страницу удалили намеренно, лучше всего настроить редирект. Редирект помогает сделать перенаправление одной страницы на другую. Это позволит сохранить поисковые позиции.

Ошибка 505 HTTP Version Not Supported

Код ошибки 505 говорит нам о том, что проблема возникла на уровне сервера. Вот что означает ошибка 505: с её помощью сервер сообщает, что не может установить соединение по той версии HTTP-протокола, с помощью которой к нему хотят подключиться.

Основные причины

1. Пользователь использует устаревший браузер, который не поддерживает новые версии протокола. То есть в этом случае браузер подключается по версии HTTP 1.1, а сервер работает по версии HTTP 2.
2. Сервер не поддерживает HTTP-протокол, с помощью которого пытается подключиться клиент. Например, он работает по версии HTTP 1.1, а запрос поступает из браузера с версии HTTP 2.
3. Неверные директивы, указанные в файле .htaccess.
4. Неполадки в работе скриптов ресурса.

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

Если вы пользователь:

1. Почистите файлы cookies и кэш браузера.
2. Обновите версию браузера.
3. Обновите операционную систему и драйверы.
4. Обратитесь к интернет-провайдеру. Если все страницы показывают 505 в любых браузерах, обратитесь в службу поддержки вашего провайдера.

Если вы владелец сайта:

1. Узнайте, по какой версии протокола работает ваш сайт. Обновите её до актуальной, если необходимо. Например, серверы REG.RU работают с протоколом HTTP 1.1.
2. Проверьте логи веб-сервера. Определите, где кроется ошибка (в работе CGI-скриптов, директивах .htaccess или файле конфигурации веб-сервера) и исправьте её.
3. Если проблема в скриптах, обратитесь к разработчику сайта.