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="tcp://Server";Ref="demo";"
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
Код состояния 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¶m2=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
Снимает привязку одного ресурса к другому.
Здравствуйте.
Ситуация следующая. Собрал конфигурацию из базовых подсистем БСП, дописал свои объекты, создал Web-сервис, при первой публикации Web-сервис работал без ошибок, потребовалось внести незначительные изменения, стал выдавать ошибку:
Ошибка работы с Интернет: запрос не допустим для заданного ресурса (406). <?xml version=»1.0″ encoding=»UTF-8″?><?xml-stylesheet type=»text/xsl» href=»http://nipi-1c-00/1c83_WorkHours/e1csys/vrscore/exception.xslt?sysver=8.3.10.2650″?><exception xmlns=»http://v8.1c.ru/8.2/virtual-resource-system»; xmlns:xs=»http://www.w3.org/2001/XMLSchema»; xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance»; xsi:type=»Exception» clsid=»580392e6-ba49-4280-ac67-fcd6f2180121″ reason=»406″><descr xmlns=»http://v8.1c.ru/8.1/data/core»>Истекло время ожидания сеанса</descr></exception>
по причине:
Ошибка работы с Интернет: запрос не допустим для заданного ресурса (406)
Перезагрузил сервер, все нормализовалось, теперь снова потребовалось внести изменения в конфигураторе, теперь уже не в самом Web-сервис, сохранил конфигурацию, опять ошибка, все смотрел не могу понять, самое интересное, что при этом типовой Web-сервис от БСП работает, а мой — нет.
Прошу помощи есть предположения, куда смотреть?
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="tcp://Server";Ref="demo";"
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
- Remove From My Forums
-
Вопрос
-
Пытаюсь поднять локальный сервер обновлений для Adobe. В общем-то, сервером это назвать сложно, с помощью их утилиты формируется структура папок, она же скачивает собственно обновления и xml файлы с настройками к ним. Нужно только отдавать все это с помощью
какого-то web сервера.Пытаюсь отдать все это с IIS 7.5 (Windows 2008 R2). При доступе из браузера файлы отдаются нормально, когда туда же «стучится» утилита обновления из комплекта Adobe CS5, то получает ошибку 406 —
Client browser does not accept the MIME type of the requested pageСамое интересное в том, что если положить ту же стурктура на apache, то все работает без вопросов.
Обращение идет к двум типам файлов — xml и zip. Обращения к xml удалось победить с помощью прописывания в
Handler Mappings Add Script Map на asp.dll. Кому интересно — подробности прописывания (http://itpadla.wordpress.com/tag/adobe-update-server/)Вопрос в том, что прописать для zip файлов, чтобы избавиться от 406 ошибки?
Ответы
-
Пытаюсь отдать все это с IIS 7.5 (Windows 2008 R2). При доступе из браузера файлы отдаются нормально, когда туда же «стучится» утилита обновления из комплекта Adobe CS5, то получает ошибку 406 —
Client browser does not accept the MIME type of the requested pageКлиент просто не понимает ответ сервера. Вы посмотрите какой заголовок получает клиент. Особенно Accept: И сравните с вариантом Apache. После этого будет ясно куда надо покручивать IIS.
Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
-
Предложено в качестве ответа
14 января 2011 г. 8:27
-
Помечено в качестве ответа
Nikita Panov
21 января 2011 г. 12:11
-
Предложено в качестве ответа
I’m making a web site that must conform to MobileOK.
When I run the validator, it receives a «406» error whenever it attempts to retrieve a jpeg or png file, but gif files are fine.
What I think is causing it is that the «Accept:» header sent by the MobileOK validator doesn’t include «image/png» or «image/jpg», rather it only includes «image/jpeg» and «image/gif».
So, I stripped all of the png files out of the site and replaced them with gif and jpeg files, renaming any «.jpg» to «.jpeg». I also added in the IIS MIME configuration to map any .jpg, .jpeg file extensions to the «image/jpeg» MIME type.
However, the validator keeps encountering error 406.
How do I solve this? Is there a way to fix it, a way to work around it, or a way to fool it?
As far as I know, the server has a clean installation of Windows Server 2003 with no modifications.
In response to kroonwijk, I can’t give you an actual excerpt as I’ve for now just converted everything to .gif, and I don’t have a live copy of the problematic site. However, the MobileOK site gave me a «IMAGE_FOR_SPACING» failure (claiming I had a very small, transparent image present) whenever it was validating a page including a png or jpeg file, and a «MAIN_DOCUMENT» error (with the site code given as a IIS 406 error) when I targeted the image itself with the validator.
The IIS log simply logged the time, IP of the validator, and the code 406. I’m now suspecting that somewhere along the way the Accept: header got truncated before it actually got to the IIS server… how would I view the actual accept header as is arrives?
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="tcp://Server";Ref="demo";"
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
Код состояния 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¶m2=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, даже если она не является истинным источником проблемы. Например, можно столкнуться с ошибкой HTTP 404 (Страница не найдена) при посещения веб-страницы которая на самом деле функционирует должным образом.
Ваш интернет-браузер может отображать ошибку 406 в результате заражения вредоносным ПО. Такое вредоносное ПО может привести к неверной работе браузера и вызвать повреждения реестра Windows, что приведет к еще более раздражающим сообщениям об ошибках.
Коды состояний браузера в базе знаний
Как исправить ошибку HTTP 406 (Not Acceptable)
Ниже описана последовательность действий по устранению ошибок, призванная решить проблемы Not Acceptable. Данная последовательность приведена в порядке от простого к сложному и от менее затратного по времени к более затратному, поэтому мы настоятельно рекомендуем следовать данной инструкции по порядку, чтобы избежать ненужных затрат времени и усилий.
Шаг 1: Восстановить записи реестра, связанные с ошибкой 406
Редактирование реестра Windows вручную с целью удаления содержащих ошибки ключей Not Acceptable не рекомендуется, если вы не являетесь специалистом по обслуживанию ПК. Ошибки, допущенные при редактировании реестра, могут привести к неработоспособности вашего ПК и нанести непоправимый ущерб вашей операционной системе. На самом деле, даже одна запятая, поставленная не в том месте, может воспрепятствовать загрузке компьютера!
В связи с подобным риском мы настоятельно рекомендуем использовать надежные инструменты очистки реестра, такие как Reimage (разработанный Microsoft Gold Certified Partner), чтобы просканировать и исправить любые проблемы, связанные с Ошибка 406. Используя очистку реестра, вы сможете автоматизировать процесс поиска поврежденных записей реестра, ссылок на отсутствующие файлы (например, вызывающих ошибку Not Acceptable) и нерабочих ссылок внутри реестра. Перед каждым сканированием автоматически создается резервная копия, позволяющая отменить любые изменения одним кликом и защищающая вас от возможного повреждения компьютера. Самое приятное, что устранение ошибок реестра может резко повысить скорость и производительность системы.
Предупреждение: Если вы не являетесь опытным пользователем ПК, мы НЕ рекомендуем редактирование реестра Windows вручную. Некорректное использование Редактора реестра может привести к серьезным проблемам и потребовать переустановки Windows. Мы не гарантируем, что неполадки, являющиеся результатом неправильного использования Редактора реестра, могут быть устранены. Вы пользуетесь Редактором реестра на свой страх и риск.
Перед тем, как вручную восстанавливать реестр Windows, необходимо создать резервную копию, экспортировав часть реестра, связанную с Not Acceptable (например, Windows Operating System):
Следующие шаги при ручном редактировании реестра не будут описаны в данной статье, так как с большой вероятностью могут привести к повреждению вашей системы. Если вы хотите получить больше информации о редактировании реестра вручную, пожалуйста, ознакомьтесь со ссылками ниже.
Мы не несем никакой ответственности за результаты действий, совершенных по инструкции, приведенной ниже — вы выполняете эти задачи на свой страх и риск.
Шаг 2: Проведите полное сканирование вашего компьютера на вредоносное ПО
Есть вероятность, что ошибка Not Acceptable может быть связана с заражением вашего компьютера вредоносным ПО. Эти вредоносные злоумышленники могут повредить или даже удалить файлы, связанные с Коды состояний браузера. Кроме того, существует возможность, что ошибка 406 связана с компонентом самой вредоносной программы.
Совет: Если у вас еще не установлены средства для защиты от вредоносного ПО, мы настоятельно рекомендуем использовать Emsisoft Anti-Malware (скачать). В отличие от других защитных программ, данная программа предлагает гарантию удаления вредоносного ПО.
Шаг 3: Очистить систему от мусора (временных файлов и папок) с помощью очистки диска (cleanmgr)
Со временем ваш компьютер накапливает ненужные файлы в связи с обычным интернет-серфингом и повседневным использованием компьютера. Если такие ненужные файлы иногда не удалять, они могут привести к снижению быстродействия Windows Operating System или к ошибке Not Acceptable, возможно вследствие конфликтов файлов или перегрузки жесткого диска. Удаление таких временных файлов при помощи утилиты Очистка диска может не только устранить ошибку 406, но и существенно повысить быстродействие вашего компьютера.
Совет: Хотя утилита Очистки диска является прекрасным встроенным инструментом, она удаляет не все временные файлы с вашего компьютера. Другие часто используемые программы, такие как Microsoft Office, Firefox, Chrome, Live Messenger, а также сотни других программ не поддаются очистке при помощи программы Очистка диска (включая некоторые программы Microsoft Corporation).
Из-за недостатков утилиты Windows Очистка диска (cleanmgr) мы настоятельно рекомендуем использовать специализированное программное обеспечение очистки жесткого диска / защиты конфиденциальности, например WinSweeper [Загрузить] (разработано Microsoft Gold Partner), для очистки всего компьютера. Запуск WinSweeper [Загрузить] раз в день (при помощи автоматического сканирования) гарантирует, что ваш компьютер всегда будет чист, будет работает быстро и без ошибок Not Acceptable, связанных с временными файлами.
Как запустить Очистку диска (cleanmgr) (Windows XP, Vista, 7, 8 и 10):
Шаг 4: Обновите драйверы устройств на вашем компьютере
Ошибки Not Acceptable могут быть связаны с повреждением или устареванием драйверов устройств. Драйверы с легкостью могут работать сегодня и перестать работать завтра по целому ряду причин. Хорошая новость состоит в том, что чаще всего вы можете обновить драйверы устройства, чтобы устранить проблему с Ошибка 406.
В связи с временными затратами и общей сложностью обновления драйверов мы настоятельно рекомендуем использовать утилиту обновления драйверов, например DriverDoc (разработана Microsoft Gold Partner), для автоматизации этого процесса.
Пожалуйста, учтите: Ваш файл Not Acceptable может и не быть связан с проблемами в драйверах устройств, но всегда полезно убедиться, что на вашем компьютере установлены новейшие версии драйверов оборудования, чтобы максимизировать производительность вашего ПК.
Шаг 5: Используйте Восстановление системы Windows, чтобы «Отменить» последние изменения в системе
Восстановление системы Windows позволяет вашему компьютеру «отправиться в прошлое», чтобы исправить проблемы Ошибка 406. Восстановление системы может вернуть системные файлы и программы на вашем компьютере к тому времени, когда все работало нормально. Это потенциально может помочь вам избежать головной боли от устранения ошибок, связанных с Not Acceptable.
Пожалуйста, учтите: использование восстановления системы не повлияет на ваши документы, изображения или другие данные.
Чтобы использовать Восстановление системы (Windows XP, Vista, 7, 8 и 10):
Шаг 6: Удалите и установите заново программу Windows Operating System, связанную с Not Acceptable
Инструкции для Windows 7 и Windows Vista:
Инструкции для Windows XP:
Инструкции для Windows 8:
После того, как вы успешно удалили программу, связанную с Not Acceptable (например, Windows Operating System), заново установите данную программу, следуя инструкции Microsoft Corporation.
Совет: Если вы абсолютно уверены, что ошибка 406 связана с определенной программой Microsoft Corporation, удаление и повторная установка программы, связанной с Not Acceptable с большой вероятностью решит вашу проблему.
Шаг 7: Запустите проверку системных файлов Windows («sfc /scannow»)
Проверка системных файлов представляет собой удобный инструмент, включаемый в состав Windows, который позволяет просканировать и восстановить поврежденные системные файлы Windows (включая те, которые имеют отношение к Not Acceptable).
Чтобы запустить проверку системных файлов (Windows XP, Vista, 7, 8 и 10):
Шаг 8: Установите все доступные обновления Windows
Microsoft постоянно обновляет и улучшает системные файлы Windows, связанные с Not Acceptable. Иногда для решения проблемы Коды состояний браузера нужно просто напросто обновить Windows при помощи последнего пакета обновлений или другого патча, которые Microsoft выпускает на постоянной основе.
Чтобы проверить наличие обновлений Windows (Windows XP, Vista, 7, 8 и 10):
Шаг 9: Произведите чистую установку Windows
Предупреждение: Мы должны подчеркнуть, что переустановка Windows займет очень много времени и является слишком сложной задачей, чтобы решить проблемы Ошибка 406. Во избежание потери данных вы должны быть уверены, что вы создали резервные копии всех важных документов, изображений, программ установки программного обеспечения и других персональных данных перед началом процесса. Если вы сейчас е создаете резервные копии данных, вам стоит немедленно заняться этим (скачать рекомендованное решение для резервного копирования), чтобы защитить себя от безвозвратной потери данных.
Пожалуйста, учтите: Если проблема 406 не устранена после чистой установки Windows, это означает, что проблема Коды состояний браузера ОБЯЗАТЕЛЬНО связана с аппаратным обеспечением. В таком случае, вам, вероятно, придется заменить соответствующее оборудование, вызывающее ошибку 406.
Информация об операционной системе
Сообщения об ошибках Not Acceptable могут появляться в любых из нижеперечисленных операционных систем Microsoft Windows:
Проблема с Ошибка 406 (Not Acceptable) все еще не устранена?
Обращайтесь к нам в любое время в социальных сетях для получения дополнительной помощи:
Об авторе: Джей Гитер (Jay Geater) является президентом и генеральным директором корпорации Solvusoft — глобальной компании, занимающейся программным обеспечением и уделяющей основное внимание новаторским сервисным программам. Он всю жизнь страстно увлекался компьютерами и любит все, связанное с компьютерами, программным обеспечением и новыми технологиями.
Появляется во время редактирования записей, страниц, товаров и записей др. таксономий. При этом отредактировать контент невозможно.
Текст ошибки выглядит следующим образом:
Not Acceptable
An appropriate representation of the requested resource /wp-admin/post. php could not be found on this server.
Причина появления этой ошибки
На сервере вашего хостинга который работает на Apache, устанавливают ModSecurity — брандмауэр веб-приложений с открытым исходным кодом. Это приложение устанавливают, чтобы защитить вебхостинг от взлома и всяких зловредных запросов, которые может посылать ваш сайт. Что будет блокировать данное приложение, а что не будет зависит от установленных правил безопасности.
Если сайт, страница или функция нарушают одно из этих правил, сервер может отправить ошибку 406 Not Acceptable. При этом скрипт/код на вашем сайте абсолютно не является зловредным или опасным для хостинга.
Если у вас на сайте внезапно появилась такая ошибка, то начинайте вспоминать, что вы в последнее время обновляли на сайте и какой код устанавливали.
Ошибка может быть вызвана обновлением плагина, или установкой кода от стороннего сервиса. Например, в сети встречал примеры когда такая ошибка появлялась после установки кода от рекламной сети яндекса, или кода баннеров.
Как исправить эту проблему?
1. Найти код, который вызывает ошибку и удалить его. Но, ведь код сам по себе не является зловредным и нам он нужен. Тогда переходим к следующим пунктам.
2. Откройте файл .htaccess (лежит в корне сайта) и вставьте этот фрагмент кода:
Этот код отключает фильтры брандмауэра ModSecurity по отношению к вашему сайту. Если не помогло, смотрим следующий пункт.
3. Отключаем ModSecurity в панели хостинга CPanel.
Войдите в панель управления, найдите блок Безопасность. Нажмите на ссылку ModSecurity.
На следующей странице отключите это приложение для всех ваших доменов или для конкретного сайта.
The 406 Not Acceptable is an HTTP response status code indicating that the client has requested a response using Accept — headers that the server is unable to fulfill. This is typically a result of the user agent (i. e. browser) specifying an acceptable character set (via Accept-Charset ), language (via Accept-Language ), and so forth that should be responded with, and the server being unable to provide such a response.
Like most HTTP response codes — especially for those that indicate an error — the cause of a 406 Not Acceptable error code can be difficult to track down and fix. With a potential pool of over 50 status codes that represent the complex relationship between the client, a web application, a web server, and often multiple third-party web services, determining the cause of a particular status code can be a challenge under the best of circumstances.
In this article we’ll examine the 406 Not Acceptable in more detail by looking at what might cause a message, along with a handful of tips for diagnosing and debugging the appearance of this error within your own application. We’ll even examine a number of the most popular content management systems ( CMSs ) for potential problem areas that could cause your own website to be generating a 406 Not Acceptable unexpectedly. Let’s dive in!
Server — or Client-Side?
Start With a Thorough Application Backup
As with anything, it’s better to have played it safe at the start than to screw something up and come to regret it later on down the road. As such, it is critical that you perform a full backup of your application, database, and all other components of your website or application before attempting any fixes or changes to the system. Even better, if you have the capability, create a complete copy of the application and stick the copy on a secondary staging server that isn’t active or is inaccessible to the public. This will give you a clean testing ground with which to test all potential fixes to resolve the issue, without threatening the security or sanctity of your live application.
Diagnosing a 406 Not Acceptable
As discussed in the introduction, a 406 Not Acceptable indicates that the user agent (the web browser, in most cases) has requested a valid resource, however the request included a special Accept — header that indicates to the server a valid response can only contain certain types of information. Here are a few examples of such scenarios:
There are handful of other Accept — headers that can be provided in HTTP requests, but the vast majority of scenarios are similar to above: The user agent wants an explicit type of response, and the server either provides it, or it may return a 406 code indicating it cannot fulfill the request.
Troubleshooting on the Client-Side
Since the 406 Not Acceptable is a client error response code, it’s best to start by troubleshooting any potential client-side issues that could be causing this error. Here are a handful of tips to try on the browser or device that is giving you problems.
Check the Requested URL
The most common cause of a 406 Not Acceptable is simply inputting an incorrect URL. Many servers are tightly secured, so as to disallow unexpected requests to resources that a client/user agent should not have access to. It may be that the requested URL is slightly incorrect, which is causing the user agent to request a specific type of response. For example, a request to the URI https://airbrake. io? json might indicate to the server that a JSON response is required. Since 406 codes are not as common as 404 codes, the appearance of a 406 could means that the requested URL is valid, but the browser may be misinterpreting the intended request type. Either way, it’s a good idea to double-check the exact URL that is returning the 406 Not Acceptable error to make sure it is intended resource.
Debugging Common Platforms
There are a few tips below aimed at helping you troubleshoot some of these popular software platforms.
Rollback Recent Upgrades
If you recently updated the content management system itself just before the 406 Not Acceptable appeared, you may want to consider rolling back to the previous version you had installed when things were working fine. Similarly, any extensions or modules that you may have recently upgraded can also cause server-side issues, so reverting to previous versions of those may also help. For assistance with this task, simply Google “downgrade [PLATFORM_NAME]” and follow along. In some cases, however, certain CMSs don’t really provide a version downgrade capability, which indicates that they consider the base application, along with each new version released, to be extremely stable and bug-free. This is typically the case for the more popular platforms, so don’t be afraid if you can’t find an easy way to revert the platform to an older version.
Uninstall New Extensions, Modules, or Plugins
Depending on the particular content management system your application is using, the exact name of these components will be different, but they serve the same purpose across every system: improving the capabilities and features of the platform beyond what it’s normally capable of out of the box. But be warned: such extensions can, more or less, take full control of the system and make virtually any changes, whether it be to the PHP code, HTML, CSS, JavaScript, or database. As such, it may be wise to uninstall any new extensions that may have been recently added. Again, Google the extension name for the official documentation and assistance with this process.
Check for Unexpected Database Changes
Troubleshooting on the Server-Side
If you aren’t running a CMS application — or even if you are, but you’re confident the 406 Not Acceptable isn’t related to that — here are some additional tips to help you troubleshoot what might be causing the issue on the server-side of things.
Confirm Your Server Configuration
For example, here is a simple RewriteRule that matches all incoming requests to https://airbrake. io/users/json that do not contain an Accept: application/json request header. The result is a redirection and 406 Not Acceptable response error code:
Have a look through your nginx. conf file for any abnormal directives or lines that include the 406 flag. Comment out any abnormalities before restarting the server to see if the issue was resolved.
Configuration options for each different type of web server can vary dramatically, so we’ll just list a few popular ones to give you some resources to look through, depending on what type of server your application is running on:
Look Through the Logs
Nearly every web application will keep some form of server-side logs. Application logs are typically the history of what the application did, such as which pages were requested, which servers it connected to, which database results it provides, and so forth. Server logs are related to the actual hardware that is running the application, and will often provide details about the health and status of all connected services, or even just the server itself. Google “logs [PLATFORM_NAME]” if you’re using a CMS, or “logs [PROGRAMMING_LANGUAGE]” and “logs [OPERATING_SYSTEM]” if you’re running a custom application, to get more information on finding the logs in question.
Debug Your Application Code or Scripts
If all else fails, it may be that a problem in some custom code within your application is causing the issue. Try to diagnose where the issue may be coming from through manually debugging your application, along with parsing through application and server logs. Ideally, make a copy of the entire application to a local development machine and perform a step-by-step debug process, which will allow you to recreate the exact scenario in which the 406 Not Acceptable occurred and view the application code at the moment something goes wrong.
No matter the cause — and even if you managed to fix it this time — the appearance of an issue like the 406 Not Acceptable within your own application is a good indication you may want to implement an error management tool, which will help you automatically detect errors and will alert you the very moment they occur. Airbrake’s error monitoring software provides real-time error monitoring and automatic exception reporting for all your development projects. Airbrake’s state of the art web dashboard ensures you receive round-the-clock status updates on your application’s health and error rates. No matter what you’re working on, Airbrake easily integrates with all the most popular languages and frameworks. Plus, Airbrake makes it easy to customize exception parameters, while giving you complete control of the active error filter system, so you only gather the errors that matter most.
Check out Airbrake’s error monitoring software today and see for yourself why so many of the world’s best engineering teams use Airbrake to revolutionize their exception handling practices!
Настройка веб-публикации 1С, подключение кассового оборудования
Устанавливаем веб-сервер Internet Information Server, который по умолчанию входит в поставку Microsoft Windows Server. При установке обязательно выбираем компоненты:
2. Публикации базы в 1С
На этот же сервер, где развернут веб-сервер IIS, устанавливаем «1С:Предприятие» (32-разрядные компоненты), обязательно выбрав при установке компоненты:
Если планируется настроить 64-разрядный модуль расширения веб-сервера, то необходимо дополнительно запустить программу установки 64-разрядного сервера из соответствующей поставки «1С:Предприятие» и установить компоненту:
2.1 Настройка прав доступа для IIS
Теперь необходимо установить необходимые права на ключевые папки, используемые при работе веб-доступа к базам данных «1С:Предприятие». Для каталога хранения файлов веб-сайтов, опубликованных на веб-сервере (по-умолчанию: C:\inetpub\wwwroot\), необходимо дать полные права группе «Пользователи» (Users). В принципе, этот шаг можно пропустить, но тогда для публикации или изменения публикации базы данных надо будет запускать «1С:Предприятие» от имени администратора. Для настройки безопасности данного каталога, кликаем по нему правой кнопкой мыши и в контекстном меню выбираем «Свойства» (Properties).
В открывшемся окне свойств, переходим на вкладку «Безопасность» (Security) и нажимаем кнопку «Изменить» (Edit…), для изменения действующих разрешений. Появится окно разрешений для данного каталога. В списке Групп или пользователей (Groups or user names) выделим группу «Пользователи» (Users) и в списке разрешений для выбранной группы установим флаг «Полный доступ» (Full control). Затем нажмем «Применить» (Apply) для записи изменений и закроем все окна при помощи кнопки «ОК».
Далее необходимо дать полные права на каталог с установленными файлами «1С:Предприятие» (по-умолчанию: C:\Program Files (x86)\1cv8\ для 32-разрядного модуля расширения и C:\Program Files\1cv8\ для 64-разрядного) группе IIS_IUSRS. Для этого выполняем аналогичные описанным выше действия, с той лишь разницей, что для того, чтобы необходимая группа появилась в списке «Группы или пользователи» (Groups or user names), необходимо нажать расположенную под списком кнопку «Добавить» (Add..), а в окне выбора групп или пользователей нажать «Дополнительно» (Advanced…).
Затем нажимаем расположенную справа кнопку «Поиск» (Find Now), после чего выбираем необходимую группу IIS_IUSRS в таблице результатов поиска и нажимаем «ОК».
И, наконец, если публикация выполняется для файловой базы, необходимо также дать группе IIS_IUSRS полные права на каталог с расположенными файлами данной информационной базы.
2.2 Публикация базы данных на веб-сервере
Переходим к непосредственной публикации базы данных на веб-сервере. Для этого запускаем «1С:Предприятие» в режиме Конфигуратор для той базы, которую требуется опубликовать. Затем в меню выбираем «Администрирование» — «Публикация на веб-сервере…»
Откроется окно настройки свойств публикации на веб-сервере. Основные поля, необходимые для публикации, уже заполнены по-умолчанию:
Выбрав необходимые настройки публикации, нажимаем «Опубликовать».
Если публикация прошла без ошибок, увидим соответствующее сообщение.
2.3 Подключение к опубликованной информационной базе через веб-браузер
Для подключений к опубликованной базе данных запускаем Internet Explorer, в строке адреса вводим путь вида https://localhost/<Имя публикации информационной базы>. В данном примере это https://https://localhost/BP.
3. Создание бесплатного SSL-сертификата Let’s Encrypt на IIS
Наличие SSL-сертификата для сайта позволяет защитить данные пользователей, передаваемые по сети от атак человек-посередине (man-in-the-middle) и гарантировать целостность переданных данных.
Let’s Encrypt – это некоммерческий центр сертификации, позволяющий в автоматическом режиме через API выпускать бесплатные SSL/TLS сертификаты. Выдаются только сертификаты для валидации доменов (domain validation) со сроком действия 90 дней, что не является проблемой из-за наличия встроенной возможности автоматического перевыпуска сертификата, в результате чего обеспечивается непрерывность защиты.
Далее описан способ получить SSL-сертификат от Let’s Encrypt при помощи консольной утилиты LetsEncrypt-Win-Simple. Она представляет собой простой мастер, который позволяет выбрать один из сайтов, запущенных на IIS и автоматически выпустить и привязать к нему SSL-сертификат.
3.1 Создание SSL-сертификата
Скачиваем последний релиз клиента со страницы проекта на GitHub https://github. com/PKISharp/win-acme/releases
Распакуем его в каталог на сервере с IIS: c:\inetpub\letsencrypt
Запустится интерактивный мастер, который сначала попросит указать ваш e-mail, на который будут отправляться уведомления о проблемах с обновлением сертификата, и согласиться с пользовательским соглашением.
Затем нужно будет выбрать, что необходимо создать новый сертификат (N: Create new certificate) и выбрать тип сертификата (в нашем примере нет необходимости использовать сертификат с несколькими SAN), поэтому достаточно выбрать пункт 1. Single binding of an IIS site.
Далее утилита выведет список запущенных на IIS сайтов и предложит выбрать сайт, для которого нужно выпустить сертификат.
Следующий этап – выполнение валидации домена. Доступно несколько вариантов валидации: TLS, через запись в DNS или через HTTP). Самый простой вариант — выбрать пункт 4 [http-01] Create temporary application in IIS (recommended). В этом случае на веб-сервере будет создано небольшое приложение, через которое серверы Let’s Encrypt смогут провести валидацию.
Примечание. При выполнении TLS/HTTP проверки ваш сайт должен быть доступен снаружи по полному DNS имени по протоколам HTTP (80/TCP) и HTTPS (443/TCP).
После валидации утилита letsencrypt-win-simple автоматически отправит запрос на генерацию сертификата, скачает его (все необходимые файлы, а также закрытый ключ сохраняются в каталог C:\Users\User\AppData\Roaming\letsencrypt-win-simple) и создаст привязку на сайте IIS. В том случае, если на сайте уже установлен SSL-сертификат, он будет заменен новым. Кроме того, будет создано правило в планировщике заданий Windows, которое запускается каждый день и автоматически выпускает и устанавливает новый сертификат каждые 60 дней.
3.2 Создание отдельного пула и сайта с подключенным с SSL-сертификатом.
Создаем отдельный пул в IIS для letsencrypt
Добавляем сайт в новый пул. Порт указываем 443 (или другой на который позже сделаем проброс на 443 порт).
Указать новый сертификат в «Сертификаты SSL»:
Настроить привязку к нашему сайту:
Веб-публикация 1С доступна по защищенному соединению https.
4. Подключение кассового оборудования. Проброс COM-портов через TCP/IP с помощью Virtual Serial Ports Emulator (VSPE).
4.1 Настройка VSPE на сервере
Запустить программу VSPE. Нажать на кнопку «Создать новое устройство».
После нужно создать виртуальные порты (для каждой кассы свой порт). Номера портов лучше взять пониже, дабы избежать проблем.
В открывшемся окне в выпадающем меню выбрать TcpServer. Нажать кнопку «Далее».
Установить локальный номер tcp-порта, который будет прослушиваться. Выбрать COM-порт, к которому подключено оборудование через преобразователь интерфейсов. Нажать на кнопку «Настройки».
Нажать кнопку «Готово».
В появившемся окне нажать на кнопку запуска (зеленый треугольник). Серверная часть настроена.
4.2 Настройка VSPE на клиенте.
Запустить программу VSPE. Нажать на кнопку «Создать новое устройство».
В открывшемся окне в выпадающем меню выбрать «Connector».
Выбрать виртуальный COM-порт, который будет использоваться для проброса. Нажать на кнопку «Готово».
Нажать на кнопку «Создать новое устройство».
В открывшемся окне в выпадающем меню выбрать TcpClient
Указать IP-адрес удаленного сервера и номер TCP-порта, на который будет осуществляться подключение. Выбрать виртуальный COM-порт, который будет использоваться для соединения.
В появившемся окне нажать на кнопку запуска (зеленый треугольник). Клиентская часть готова.
После меняем настройки 1С на наши виртуальные порты. Делаем тестирование.
5. Примечание
Несколько нюансов данного ПО:
Программа не сохраняет настройки автоматически и не запускается в момент старта ОС. Поэтому необходимо сохранить настроенную конфигурацию и создать ярлык с параметром:
Созданный ярлык помещаем в автозагрузку или создаем bat-файл для запуска программы с использованием сохраненной конфигурации. Bat-файл должен содержать строку следующего формата:
Для автоматического запуска программы VSPE после запуска ОС Windows следует поместить ссылку на этот bat-файл в автозагрузку или планировщик заданий. (для серверной и клиентской части).
Мы также готовы оказать помощь в настройке веб-публикации и подключении кассового оборудования.
Нашим клиентам мы предлагаем реализацию данного проекта и последующее ИТ-обслуживание в рамках ИТ-аутсорсинга.
Ошибка сервера 401: что это за ошибка и как ее исправить
Появление сообщения об ошибке 401 Unauthorized Error («отказ в доступе») при открытии страницы сайта означает неверную авторизацию или аутентификацию пользователя на стороне сервера при обращении к определенному url-адресу. Чаще всего она возникает при ошибочном вводе имени и/или пароля посетителем ресурса при входе в свой аккаунт. Другой причиной являются неправильные настройки, допущенные при администрировании web-ресурса. Данная ошибка отображается в браузере в виде отдельной страницы с соответствующим описанием. Некоторые разработчики интернет-ресурсов, в особенности крупных порталов, вводят собственную дополнительную кодировку данного сбоя:
Попробуем разобраться с наиболее распространенными причинами возникновения данной ошибки кода HTTP-соединения и обсудим способы их решения.
Причины появления ошибки сервера 401 и способы ее устранения на стороне пользователя
При доступе к некоторым сайтам (или отдельным страницам этих сайтов), посетитель должен пройти определенные этапы получения прав:
Большинство пользователей сохраняют свои данные по умолчанию в истории браузеров, что позволяет быстро идентифицироваться на наиболее часто посещаемых страницах и синхронизировать настройки между устройствами. Данный способ удобен для серфинга в интернете, но может привести к проблемам с безопасностью доступа к конфиденциальной информации. При наличии большого количества авторизованных регистрационных данных к различным сайтам используйте надежный мастер-пароль, который закрывает доступ к сохраненной в браузере информации.
Наиболее распространенной причиной появления ошибки с кодом 401 для рядового пользователя является ввод неверных данных при посещении определенного ресурса. В этом и других случаях нужно попробовать сделать следующее:
Некоторые крупные интернет-ресурсы с большим количеством подписчиков используют дополнительные настройки для обеспечения безопасности доступа. К примеру, ваш аккаунт может быть заблокирован при многократных попытках неудачной авторизации. Слишком частые попытки законнектиться могут быть восприняты как действия бота. В этом случае вы увидите соответствующее сообщение, но можете быть просто переадресованы на страницу с кодом 401. Свяжитесь с администратором сайта и решите проблему.
Иногда простая перезагрузка проблемной страницы, выход из текущей сессии или использование другого веб-браузера полностью решают проблему с 401 ошибкой авторизации.
Устранение ошибки 401 администратором веб-ресурса
Для владельцев сайтов, столкнувшихся с появлением ошибки отказа доступа 401, решить ее порою намного сложнее, чем обычному посетителю ресурса. Есть несколько рекомендаций, которые помогут в этом:
Где в поле /oldpage. html прописывается адрес проблемной страницы, а в https://site. com/newpage. html адрес страницы авторизации.
Таким образом вы перенаправите пользователей со всех страниц, которые выдают ошибку 401, на страницу начальной авторизации.
Хотя ошибка 401 и является проблемой на стороне клиента, ошибка пользователя на стороне сервера может привести к ложному требованию входа в систему. К примеру, сетевой администратор разрешит аутентификацию входа в систему всем пользователям, даже если это не требуется. В таком случае сообщение о несанкционированном доступе будет отображаться для всех, кто посещает сайт. Баг устраняется внесением соответствующих изменений в настройки.
Дополнительная информация об ошибке с кодом 401
Веб-серверы под управлением Microsoft IIS могут предоставить дополнительные данные об ошибке 401 Unauthorized в виде второго ряда цифр:
Более подробную информацию об ошибке сервера 401 при использовании обычной проверки подлинности для подключения к веб-узлу, который размещен в службе MS IIS, смотрите здесь.
Следующие сообщения также являются ошибками на стороне клиента и относятся к 401 ошибке:
Как видим, появление ошибки авторизации 401 Unauthorized не является критичным для рядового посетителя сайта и чаще всего устраняется самыми простыми способами. В более сложной ситуации оказываются администраторы и владельцы интернет-ресурсов, но и они в 100% случаев разберутся с данным багом путем изменения настроек или корректировки html-кода с привлечением разработчика сайта.
Источники:
https://web-shpargalka. ru/http-406-not-acceptable. php
https://efsol. ru/manuals/web-iis. html
https://timeweb. com/ru/community/articles/oshibka-servera-401-chto-eto-za-oshibka-i-kak-ee-ispravit
Ошибка Not Acceptable (406)
Появляется во время редактирования записей, страниц, товаров и записей др. таксономий. При этом отредактировать контент невозможно.
Текст ошибки выглядит следующим образом:
Not Acceptable
An appropriate representation of the requested resource /wp-admin/post. php could not be found on this server.
Причина появления этой ошибки
На сервере вашего хостинга который работает на Apache, устанавливают ModSecurity — брандмауэр веб-приложений с открытым исходным кодом. Это приложение устанавливают, чтобы защитить вебхостинг от взлома и всяких зловредных запросов, которые может посылать ваш сайт. Что будет блокировать данное приложение, а что не будет зависит от установленных правил безопасности.
Если сайт, страница или функция нарушают одно из этих правил, сервер может отправить ошибку 406 Not Acceptable. При этом скрипт/код на вашем сайте абсолютно не является зловредным или опасным для хостинга.
Если у вас на сайте внезапно появилась такая ошибка, то начинайте вспоминать, что вы в последнее время обновляли на сайте и какой код устанавливали.
Ошибка может быть вызвана обновлением плагина, или установкой кода от стороннего сервиса. Например, в сети встречал примеры когда такая ошибка появлялась после установки кода от рекламной сети яндекса, или кода баннеров.
Как исправить эту проблему?
1. Найти код, который вызывает ошибку и удалить его. Но, ведь код сам по себе не является зловредным и нам он нужен. Тогда переходим к следующим пунктам.
2. Откройте файл .htaccess (лежит в корне сайта) и вставьте этот фрагмент кода:
Этот код отключает фильтры брандмауэра ModSecurity по отношению к вашему сайту. Если не помогло, смотрим следующий пункт.
3. Отключаем ModSecurity в панели хостинга CPanel.
Войдите в панель управления, найдите блок Безопасность. Нажмите на ссылку ModSecurity.
На следующей странице отключите это приложение для всех ваших доменов или для конкретного сайта.
Занимаешься созданием сайтов? Не пропусти важные новости!
Подпишись на Youtube-канал
Я рассказываю о создании сайтов простым и понятным языком, чтобы даже абсолютный новичок уже завтра смог создать свой первый интернет-магазин.
Подпишись на Telegram-канал
Получай новости на свой телефон — это удобно и быстро!
Новости из мира WordPress, полезные видео о создании сайтов, интересные статьи о разработке и безопасности.
Возникла необходимость взаимодействовать с 1C с мобильного клиента под Windows Phone 7/8. Самым простым способом взаимодействия показалось работа через web сервисы, поддерживаемые 1С.
С точки зрения публикации web сервиса особых сложностей нет. Шаги подробно описаны в статьях:
Проблемы возникли с доступом к опубликованному web-сервису 1С. Под IIS 7.5 из под Windows 2008R2 после полудня танцев с бубном проблему решить не удалось. Были изучены статьи и ветки форумов:
но счастье так и не наступило.
В результате решил, что стоит попробовать поднять web сервис на Apache, поскольку с ним у меня обычно все было несколько проще с настройкой. Итак, на другом порту (8080) на том-же сервере был поднят Apache 2.2.22. В 1С был создан ещё один web сервис и опубликован уже на Apache. С настройками по умолчанию он также не заработал. Разберем ошибки.
Web сервис был опубликован в 1С под именем wsApache.
Публикация web-сервиса 1С под Apache
Соответственно, в указанном при публикации каталоге появился файл default. vrd следующего содержания:
В httpd. conf 1С добавила следующие строчки:
В целом, файлы/изменения создаваемые 1С почти рабочие. Теперь о проблемах.
Правильный линк на сервис
В некоторых статьях путь к web сервису указан как: https://имя_сервера:порт/имя_при_публикации/alias? wsdl.
- Имя сервера: s-1s-1-hw
- Порт: 8080
- Имя при публикации: wsApache
- Alias из файла default. vrd: service.1cws
Соответственно, НЕПРАВИЛЬНАЯ ссылка на web сервис 1С такая: https://s-1c-1-hw:8080/wsApache/service.1cws? wsdl
Если использовать такой линк, то 1C 8.2 выдаст сообщение вида:
Правильный вариант:
https://имя_сервера:порт/имя_при_публикации/ ws/ alias? wsdl.
Это обращение эквивалентно обращению по имени сервиса из default. vrd:
https://имя_сервера:порт/имя_при_публикации/ ws/ name? wsdl.
Соответственно, ПРАВИЛЬНЫЙ линк для доступа к web сервису 1С будет такой:
https://s-1c-1-hw:8080/wsApache/ ws/ service.1cws? wsdl
https://s-1c-1-hw:8080/wsApache/ ws/ service? wsdl
Если указать ссылку с суффиксом? wsdl, то в веб браузере отобразиться XML файл с описанием опубликованного сервиса.
Если указать ссылку без суффикса? wsdl, то при правильной настройке должна появится страница с гиперссылкой на опубликованный сервис:
Авторизация пользователя при обращении к web сервису 1С
Если попытаться получить доступ к web сервису опубликованному под Apache не исправляя файл default. vrd, то появиться стандартный диалог авторизации:
Диалог авторизации на web сервисе 1С
В тестовой базе был заведен тестовый пользователь IUSR с полными правами с пустым паролем. Если ввести в диалог в качестве логина этого пользователя, то авторизация пройдет успешно и отобразиться либо XML файл, либо ссылка на него (см. выше).
Можно исключить запрос авторизационной информации вбив логин и пароль прямо в файл default. vrd, что, конечно, не рекомендуется с точки зрения безопасности, но иногда необходимо.
Это все. В моем случае каких-то дополнительных правок конфиг файлов не потребовалось.
В некоторых статьях указывалось, что нужно убрать из httpd. conf опцию «Options None«. У меня работает в обоих вариантах, т. е. когда строка присутствует и когда она удалена.
Публикация web сервиса 1С на IIS 7.5
Как уже упоминал выше, с публикацией web сервиса на IIS 7.5 с первого раза у меня не задалось, хотя тонкий клиент запускается без проблем. Поскольку пароль в конфигурационном файле по соображениям безопасности меня не устраивал, вернулся к вопросу настройки IIS. Был опубликован web сервис с именем wsIIS и именем сервиса ServiceIIS и alias-ом serviceIIS.1cws. Галка в чекбоксе «Использовать аутентификацию операционной системы на веб-сервере» для простоты эксперимента была снята.
Публикация web сервиса 1С в IIS 7.5.
Корректная ссылка в моем случае: https://s-1c-1-hw/wsIIS/ws/ServiceIIS? wsdl. При попытке зайти из Chrome/IE получаем ошибку возвращенную IIS:
дабы избавиться от ошибки правим web. config сформированный 1С следующим образом:
Эта правка эквивалента изменению через консоль управления IIS для нашего опубликованного приложения с именем wsIIS правил авторизации пользователя.
Настройки IIS 7.5 для доступа к web сервисам 1C
Добавление тегов security в web. config или правка правил авторизации в консоли IIS приводит к тому, что при обращении к сервису по указанной выше ссылке появляется запрос на авторизацию. Вводим нашего тестового пользователя IUSR без пароля и получаем нужный XML файл в ответе сервера.
Прописав в default. vrd логин и пароль пользователя, как было указано выше для Apache, уберем окно авторизации и сервис будет всегда авторизовываться под указанным пользователем. Как проходит авторизация можно посмотреть в логах 1C. Но вариант с прописыванием пользователя в конфигурационный файл — не наш путь, ибо не секьюрно.
Изменим настройки авторизации пользователя (в IIS проверка подлинности), чтобы использовалась Windows авторизация. Сменить можно в консоли управления IIS, либо в конфигурационном файле. Мне больше нравиться конфигурационный файл. так как проще переносить настройки при миграции на другой сервер.
Источники:
https://inwebpress. ru/oshibka-not-acceptable-406/
https://www. bizkit. ru/2013/05/24/1722/
Здравствуйте.
Ситуация следующая. Собрал конфигурацию из базовых подсистем БСП, дописал свои объекты, создал Web-сервис, при первой публикации Web-сервис работал без ошибок, потребовалось внести незначительные изменения, стал выдавать ошибку:
Ошибка работы с Интернет: запрос не допустим для заданного ресурса (406). <?xml version=»1.0″ encoding=»UTF-8″?><?xml-stylesheet type=»text/xsl» href=»http://nipi-1c-00/1c83_WorkHours/e1csys/vrscore/exception.xslt?sysver=8.3.10.2650″?><exception xmlns=»http://v8.1c.ru/8.2/virtual-resource-system»; xmlns:xs=»http://www.w3.org/2001/XMLSchema»; xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance»; xsi:type=»Exception» clsid=»580392e6-ba49-4280-ac67-fcd6f2180121″ reason=»406″><descr xmlns=»http://v8.1c.ru/8.1/data/core»>Истекло время ожидания сеанса</descr></exception>
по причине:
Ошибка работы с Интернет: запрос не допустим для заданного ресурса (406)
Перезагрузил сервер, все нормализовалось, теперь снова потребовалось внести изменения в конфигураторе, теперь уже не в самом Web-сервис, сохранил конфигурацию, опять ошибка, все смотрел не могу понять, самое интересное, что при этом типовой Web-сервис от БСП работает, а мой — нет.
Прошу помощи есть предположения, куда смотреть?