Что такое код xmlrpc_server_destroy

Содержание

Что такое код xmlrpc_server_destroy

xmlrpc_server_destroy — разрушает ресурсы сервера.

Описание

void xmlrpc_server_destroy (resource server)

Эта функция — ЭКСПЕРИМЕНТАЛЬНАЯ. Поведение, имя и всё остальное, что задокументировано для данной функции может быть изменено в будущих релизах РНР без предупреждения. Вы можете использовать эту функцию только на свой страх и риск.

Предупреждение!

Эта функция в настоящее время ещё не задокументирована; имеется только список аргументов.

Серверные классы XML-RPC и XML-RPCS

Класы XML-RPC CodeIgniter позволяет отправлять запросы на другой сервер, или создать свой собственный XML-RPC сервер чтобы получать запросы.

Что такое XML-RPC?

Довольно простой способ обмена данными между двумя компьютерами через интернет — использование XML. Компьютер, который отправляет XML-RPC запрос на другой компьютер, называется клиент. Принимающий запрос компьютер — сервер. Как только сервер получает и обрабатывает запрос, он отсылает назад ответ клиенту.

Например, с помощью MetaWeblog API, XML-RPC Клиент (обычно инструмент для публикаций) будет отправлять запрос на XML-RPC Сервер запущенный на вашем сайте. Этот запрос может являться новой записью блога, отправленной для публикации или это может быть запрос на редактирование существующующей записи. Когда XML-RPC Сервер получает этот запрос, он изучает его, чтобы определить, какие класс/метод должны быть вызваны для обработки запроса. После обработки сервер отправит обратно сообщение с ответом.

Подробные технические характеристики, вы можете изучить на XML-RPC сайте.

Использование XML-RPC класса

Инициализация класса

Как и большинство других классов CodeIgniter, классы XML-RPC и XML-RPCS инициализируется в вашем контроллере, используя функцию $this->load->library:

To load the XML-RPC class you will use:

После загрузки, xml-rpc библиотека объектов будет доступна через: $this->xmlrpc

Для загрузки класса XML-RPC Сервера следует использовать:

После загрузки, xml-rpcs библиотека объектов будет доступна через: $this->xmlrpcs

При использовании класса XML-RPC Сервера, следует загружать ОБА класса XML-RPC и the XML-RPC Сервер.

Отправка XML-RPC запросов

Для отправки запроса XML-RPC серверу необходимо указать следующую информацию:

  • URL сервера
  • Метод на сервере, который вы хотите использовать
  • Данные запроса (объяснение ниже).

Вот простой пример, который отправляет простой Weblogs.com пинг на Ping-o-Matic

Объяснение

Код выше инициализирует XML-RPC класс, с указанными URL сервера и методом для вызова (weblogUpdates.ping). Запрос (в нашем случае, заголовок и URL сайта) помещается в массив для отправки и компилируется функцией request(). Наконец, сформированный запрос будет отправлен. Если метод send_request() возвращает FALSE мы будет показано сообщение об ошибке отправленное XML-RPC Сервером.

Анатомия запроса

XML-RPC запрос — просто данные для передачи XML-RPC серверу. Каждая часть данных в запросе упоминается как параметр запроса. Пример выше имеет два параметра: URL и заголовок вашего сайта. Когда XML-RPC сервер получает ваш запрос, он ищет параметры в нем.

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

Вот простой пример массива с тремя параметрами:

При использовании типов данных отличных от строк или если у вас есть несколько различных типов данных, следует создать массив для каждого параметра с указанным типом данных на второй позиции:

В разделе ниже, предоставлены все типы данных.

Создание XML-RPC сервера

XML-RPC Сервер действует как «гаишник», ожидает входящие запросы и перенаправляет их в соответствующие функции для обработки.

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

Вот пример для иллюстрации:

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

Ключ ‘object’ это специальный ключ, который вы передаете в объект класса, который необходим при выполнении сопоставления метода и он не является частью CodeIgniter супер объекта.

Другими словами, если XML-RPC Клиент отправляет запрос в new_post метод, ваш сервер загрузит класс My_blog и вызовет new_entry функцию. Если запрос в update_post метод, ваш сервер загрузит класс My_blog и вызовет метод update_entry() .

Имена функции в примере выше являются произвольными. Вы сами решите как они должны называться на вашем сервере или если вы используете стандартизированный API, такие как Blogger или MetaWeblog API, вы будете использовать их имена функций.

Есть два дополнительных ключа для настройки, которые вы можете использовать при инициализации класса сервера: debug может быть установлен в TRUE для того, чтобы включить отладку и xss_clean может быть установлен в FALSE чтобы предотвратить отправку данных через метод xss_clean() библиотеки безопасности.

Обработка запросов сервером

Когда XML-RPC Сервер получает запрос и загружает класс/метод для обработки, он передаст объект в метод содержащий данные отправленные клиентом.

В примере выше, если предлагается метод new_post, сервер будет ожидать существование класса с этим прототипом:

Переменная $request — это объект, составленный сервером, который содержит данные, отправляемые XML-RPC клиентом. Используя этот объект, вы будете иметь доступ к параметрам запроса позволяющим обработать запрос. Когда все обработаете — будете отправлять ответ обратно клиенту.

Ниже приведен реальный пример Blogger API. Один из методов в Blogger API являеся getUserInfo() . С помощью этого метода XML-RPC клиент может послать серверу имя пользователя и пароль, а в ответ сервер отправляет обратно информацию о конкретном пользователь (nickname, user ID, email и т.д.). Вот как может выглядеть функция обработки:

Примечания:

Метод output_parameters() возвращает индексированный массив соответствующий параметрам запроса отправленного клиентом. В приведенном выше примере параметрами вывода будут логин и пароль.

Если имя пользователя и пароль отправленные клиентом являются недействительными, возвращается сообщение об ошибке используя метод send_error_message() .

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

Формат ответа

Аналогично Запросам, Ответы должен быть в виде массива. Однако, в отличие от запросов, ответ это массив который содержит один элемент. Этот элемент может быть массивом с несколькими дополнительными массивами, но там может быть только один индекс первичного массива. Иными словами, прототип этого:

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

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

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

Отправляем ответ ошибки

Если вам нужно отправить клиенту сообщение об ошибке, следует использовать следующие:

Первый параметр — номер ошибки, в то время как второй параметр — сообщение об ошибке.

Создание своих Клиента (Client) и Сервера (Server)

Чтобы помочь вам понять все, что мы рассмотрели до сих пор, давайте создадим пару контроллеров, которые действуют как XML-RPC Клиент и Сервер. Вы будете использовать клиент для отправки запроса на сервер и получите ответ.

Клиент (Client)

Используя текстовый редактор, создайте контроллер c названием Xmlrpc_client.php. Поместите в него этот код и сохраните этот файл в application/controllers/ каталоге:

В приведенном выше коде мы используем “url хелпер”. Вы можете найти больше информации на странице функции хелперов (помощников).

Сервер (Server)

Используя текстовый редактор, создайте контроллер c названием Xmlrpc_server.php. Поместите в него этот код и сохраните этот файл в application/controllers/ каталоге:

Пробуем!

Теперь посетите ваш сайт используя URL похожий на этот:

Теперь вы должны увидеть сообщение, которое вы отправили на сервер, и его ответ.

Созданный вами клиент отправляет сообщение (“How’s is going?”) на сервер, в “Greetings” метод. Сервер получает запрос и сопоставляет его с process() методом, где отправляется ответ.

Использование ассоциативных массивов параметром запроса

Если вы хотите использовать ассоциативный массив в параметрах метода вам нужно будет использовать тип данных struct:

Можно получить ассоциативный массив при обработке запроса на сервере.

Типы данных

Согласно XML-RPC spec существует семь типов значений, которые вы можете отправить через XML-RPC:

Справка класса

>CI_Xmlrpc initialize( [ $config = array() ] )

Предупреждение!
Параметры:
  • $config (массив) – Данные конфигурации
Возвращаемый тип:

Инициализирует XML-RPC библиотеку. Принимает ассоциативный массив содержащий параметры.

server($url [ , $port = 80 [ , $proxy = FALSE [ , $proxy_port = 8080 ] ] ] )

Устанавливает URL и номер порта сервера куда будет отправлен запрос:

Основная HTTP проверка подлинности также поддерживается, просто добавьте её в URL сервера:

timeout($seconds = 5)

Параметры:
  • $url (строка) – URL XML-RPC сервера
  • $port (число) – Порт сервера
  • $proxy (строка) – Дополнительный прокси-сервер
  • $proxy_port (число) – Прослушиваемый порт прокси-сервера
Возвращаемый тип:
Параметры:
  • $seconds (число) – Время ожидания в секундах
Возвращаемый тип:

Устанавливает время ожидания (в секундах), по истечении которого запрос будет отменен:

method($function)

Параметры:
  • $function (строка) – Имя метода
Возвращаемый тип:

Устанавливает метод, который будет запрошен у XML-RPC сервера:

Где method — имя метода.

request($incoming)

Принимает массив данных и строит запрос для отправки XML-RPC серверу:

send_request()

Параметры:
  • $incoming (массив) – Данные запроса
Возвращаемый тип:
Возвращает: TRUE при удаче, FALSE при неудаче
Возвращаемый тип: булево

Метод отправки запроса. Возвращает логическое значение TRUE или FALSE на основе успеха для неудачи, что позволяет использовать условно.

display_error()

Возвращает: Строку сообщения об ошибке
Возвращаемый тип: строка

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

display_response()

Возвращает: Ответ
Возвращаемый тип: смешанный

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

send_error_message($number, $message)

Этот способ позволяет отправить сообщение об ошибке от сервера к клиенту. Первый параметр — номер ошибки, а второй параметр — сообщение об ошибке.

© Copyright 2014 — 2020, British Columbia Institute of Technology. Последнее обновление 22 Апреля 2020.

FPublisher

Web-технологии: База знаний

Документация PHP

xmlrpc_server_destroy

(PHP 4 >= 4.0.7, PHP 5)

xmlrpc_server_destroy — Destroys server resources

Описание

int xmlrpc_server_destroy ( resource $server )

Эта функция является ЭКСПЕРИМЕНТАЛЬНОЙ. Поведение этой функции, ее имя и относящаяся к ней документация могут измениться в последующих версиях PHP без уведомления. Используйте эту функцию на свой страх и риск.

К настоящему времени эта функция еще не была документирована; для ознакомления доступен только список аргументов.

Что такое код xmlrpc_server_destroy

RPC расшифровывается как Remote Procedure Call — удаленный вызов процедур с помощью XML. Как же работает XML-RPC и каковы его отличия от стандарта SOAP?

На сцене — XML-RPC

RPC — удаленный вызов процедур с помощью XML. Сама методика удаленного вызова процедуры известна давно и используется в таких технологиях, как DCOM, SOAP, CORBA. RPC предназначен для построения распределенных клиент-серверных приложений. Это дает возможность строить приложения, которые работают в гетерогенных сетях, например на компьютерах различных систем, производить удаленную обработку данных и управление удаленными приложениями.

Приведем сильно упрощенный пример. Приложение, выполняя обработку некоторых данных на локальной машине, обращается к некоторой процедуре. Если ее реализация присутствует в программе, то процедура (функция) принимает параметры, выполняет действие и возвращает некоторые данные. Если это удаленный вызов, мы должны знать, где будет исполняться наша процедура. Запрос на выполнение процедуры вместе с параметрами записывается в виде XML-документа и посредством HTTP передается по сети на другой компьютер, где из XML-документа извлекается имя процедуры, параметры и прочая нужная информация. После завершения работы процедуры формируется ответ (например, возвращаемые данные) — и он передается компьютеру, пославшему запрос. Заметим, что для прикладной программы все действия совершенно прозрачны.

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

Хорошо, предположим, у нас есть возможность удаленно вызывать процедуры и функции — чего же нам еще? А вот чего. Формат обмена данными при классической модели RPC (DCOM, CORBA) остается бинарным — а значит, работать с ним сложнее, он не слишком подходит, если надо организовать работу распределенной системы, где между отдельными участками сети стоят firewall/прокси-серверы. Технология DCOM, например, реализована для Windows-систем, CORBA функционирует на разных платформах, но наиболее полноценна ее реализация на J2EE. Значит, всегда найдется (и действительно находится) такая конфигурация сети/платформ, чтобы для реализации распределенной системы в ней ни одна технология не подходила. Так что же делать?

Задавшись этим вопросом, компания UserLand Software Inc. создала технологию XML-RPC. Основным транспортом в ней является протокол HTTP; формат данных — XML. Это снимает ограничения, налагаемые как на конфигурацию сети, так и на маршрут следования пакетов,- вызовы XML-RPC представляют собой простой тип данных text/xml и свободно проходят сквозь шлюзы везде, где допускается ретрансляция http-трафика.

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

Что же это такое?

Рассмотрение XML-RPC проведем на упрощенном тестовом примере. Для снижения затрат мы разворачиваем систему, где на один компьютер (сервер) ставится мощное ПО для перевода, проверка синтаксиса и грамматики, а все клиенты обращаются к нему посредством XML-RPC. (Конечно, этот пример выдуман, чтобы легче было познакомить читателя с технологией — но, господа программисты, кто мешает реально сделать такую систему?)

Сообщение XML-RPC передается методом POST-протокола HTTP. Сообщения бывают трех типов: запрос, ответ и сообщение об ошибке.

Параметры:
  • $number (число) – Номер ошибки
  • $message (строка) – Сообщение ошибки
Возвращает:
Возвращаемый тип:
Запрос
XML-RPC запрос Описание
POST /RPC2 HTTP/1.0
User-Agent: MyAPP-Word/5.1.2 (WinNT)
Host: server.localnet.com
Content-Type: text/xml
Content-length: 172

CheckWord

Сначала идет стандартный заголовок http-запроса. MIME-тип данных должен быть text/xml, длина также обязательно должна присутствовать и иметь корректное значение, равное длине передаваемого сообщения.
Стандартный заголовок любого корректного XML-документа.
Корневой узел. Не допускается вложенности тегов — значит, одним запросом мы можем вызвать только один метод.
Тег указывает на объект и название метода, который вызывается. Можно указывать так, как принято в языках программирования вызывать свойства класса: имя метода — через точку после имени класса. Можно также передавать пути и имя программы. Мы вызываем метод CheckWord объекта OrfoCheck.
В секции

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

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

Типы данных

В протоколе XML-RPC предусмотрено семь простых типов данных и два сложных, для передачи параметров методу и возвращаемых значений. Эти типы отображают основные типы данных реальных языков программирования. Более сложные типы, такие, например, как объекты, нужно передавать в двоичном виде или заменять структурами.

Целые числа — задаются тегом или и представляются 4-байтовыми целыми числами со знаком. Для задания отрицательных чисел ставится знак «-«, например 34, 344, -15.

Логический тип данных представляется тегом и может иметь значения 0 (false) или 1 (true). Можно использовать как 1/0, так и символьные константы true/false.

ASCII-строка — тип данных, принимаемый по умолчанию. Представляет собой просто строку символов, заключенную в теги . В качестве символов нельзя использовать служебные знаки » и представляют собой числа с плавающей точкой двойной точности. Как разделитель целой и дробной части используется знак «,». Пробелы недопустимы. Отрицательные числа задаются знаком «-» перед числом.

Дата/время. Для передачи времени/даты служит тег . Пример времени — 19980717T14:08:55 (в спецификации написано, что сервер сам должен определять, как посылать время/дату. Использовать этот тип данных, пользоваться структурой или же просто передавать дату как строку не рекомендуется).

Двоичные данные передаются в закодированном (base64) виде и описываются тегом .

Структуры. Для передачи структурированных данных можно конструировать свои структуры. Структура определяется корневым элементом , который может содержать произвольное количество элементов , определяющих каждый член структуры. Член структуры описывается двумя тегами: первый, , описывает имя члена, второй, содержит значение члена (вместе с тегом, описывающим тип данных). Например, так описывается структура с двух строковых элементов:

Ответ сервера
XML-RPC ответ Описание
HTTP/1.1 200 OK
Connection: close
Content-Length: 166
Content-Type: text/xml
Date: Fri, 17 Jul 1998 19:55:08 GMT
Server: MyWordCheckSerwer/5.1.2-WinNT

Тело ответа при ошибке приложения

faultCode
4

faultString

Too many рarameters.

Сначала идет стандартный заголовок http-ответа сервера. MIME-тип данных должен быть text/xml, длина также должна обязательно присутствовать и иметь корректное значение, равное длине передаваемого сообщения.
Стандартный заголовок любого корректного XML-документа.
Корневой узел. Не допускается вложенности тегов .
Теги

аналогичны запросу и включают один или более элементов , которые содержат значение, возвращенное методом.
Если сервер отвечает HTTP-кодом 200 ОК — это значит, что запрос успешно обработан. Он уведомляет лишь о том, что данные по сети переданы правильно и сервер сумел их корректно обработать. Но метод также может вернуть ошибку — и это уже будет ошибка не протокола, а логики приложения.
В таком случае передается сообщение и структура, которая описывает код ошибки и текстовое объяснение.
В нашем примере передается структура из двух элементов: первый элемент содержит целочисленный код ошибки (4), второй элемент — текстовая строка, описывающая ошибку (Too many рarameters — неправильное число параметров).

Окончательный вариант

Теперь можно окончательно описать работу нашего тестового примера. Итак, приложение MyAppWord (текстовый редактор) хочет перевести на английский, например, слово «world». Программа формирует запрос к серверу, вызывая процедуру перевода TranslateWord. Процедуре передается структура, содержащая слово, которое следует перевести, и направление перевода, которое задается символьной строкой — «en-ru».

POST /RPC2 HTTP/1.0
User-Agent: MyAppWord/5.1.2 (WinNT)
Host: server.localnet.com
Content-Type: text/xml
Content-length: 172

TranslateWord

Сервер, приняв наш запрос, передает его программе-демону, которая производит парсинг запроса, выделяет из него нужные данные и, найдя (например, по таблице) ссылку на нужный метод, вызывает его с переданными параметрами. Если тип и количество параметров правильные, то по окончании работы метода программа-демон принимает возвращенное значение, преобразует его в XML-описание и формирует ответ.

HTTP/1.1 200 OK
Connection: close
Content-Length: 166
Content-Type: text/xml
Date: Fri, 17 Jul 1998 19:55:08 GMT
Server: MyWordCheckSerwer/5.1.2-WinNT

MyAppWord
Сообщение об ошибке:

HTTP/1.1 200 OK
Connection: close
Content-Length: 166
Content-Type: text/xml
Date: Fri, 17 Jul 1998 19:55:08 GMT
Server: MyWordCheckSerwer/5.1.2-WinNT

faultCode
10

faultString

Перевод невозможен. Слово отсутствует в словаре.

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

Хотя наш пример, на первый взгляд, кажется надуманным и простым, тем не менее, на нем показано, как можно уже сегодня использовать XML-RPC для решения конкретных задач. Конечно, его возможности намного шире, и можно, например, представить себе распределенную ОС, построенную на XML-RPC, или системы визуализации данных, построенные по архитектуре X Window, но с применением все того же XML-RPC.

XML-RPC vs SOAP

Если для реализации удаленного вызова вы используете XML, то у вас есть выбор: использовать XML-RPC или же SOAP (Simple Object Access Protocol). О последней уже написано множество статей, поэтому предлагаем только сравнить обе технологии.

Вот некоторые характеристики, которые определяют различия XML-RPC или же SOAP:

Характеристика XML-RPC SOAP
Скалярные типы данных + +
Структуры + +
Массивы + +
Именованные массивы и структуры +
Определяемые разработчиком кодировки +
Определяемые разработчиком типы данных +
Детализация ошибок + +
Легкость освоения и практического применения +

Конечно, на первый взгляд «минус» в столбце SOAP встречается только единожды. Это создает иллюзию «всереализуемости всего» в нем. Но давайте присмотримся внимательнее. Основные типы данных у обоих конкурентов одинаковые. Но в XML-RPC отсутствует возможность задавать имена для массивов и структур (все структуры и массивы являются «анонимными»). Возможно, это упущение разработчиков, но решить эту проблему можно и самому, например вводя еще одну строковую переменную с именем массива или структуры (в случае, если таких объектов много, можно завести специальный массив «имен массивов»).

С «определяемыми разработчиком кодировками» ситуация уже серьезнее. Сам механизм подобного ограничения не совсем ясен — ни стандарт XML, ни, тем более, транспортный уровень (протокол HTTP) таких ограничений не имеют. Да и стремление сделать клиент/сервер XML-RPC как можно более простым тоже не привело бы к возникновению подобного ограничения. Хотя, с другой стороны, SOAP тоже не блещет поддержкой кодировок (US-ASCII, UTF-8, UTF-16). Правда, в обеих технологиях есть возможность обойти все эти недостатки сразу — тип данных base64. Но выход ли это?

Посмотрим теперь на пункт «легкость в освоении и применении». В свете сегодняшних темпов развития технологий и стандартов, особенно Web, этот пункт приобретает большую важность. Реальна ситуация, когда крупный проект начинает разрабатываться на самой передовой основе — а в конце работы новый стандарт не только «уже не новый», но и «уже не стандарт вообще». Недавно W3C опубликовала черновой вариант SOAP Version 1.2 — поверьте, и объем, и сложность документации впечатляют. Трудности возникают даже на этапе ознакомительного чтения, не говоря уже о разработке. А вот спецификация XML-RPC занимает около трех страниц А4 и предельно проста.

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

  • если вам нужна система для работы со сложной логикой, если вы передаете большие комплексные структуры данных, если вам нужна полная информация о клиенте, если вы хотите, чтобы запрос содержал в себе инструкции по его обработке, и, наконец, если для вас важно, чтобы за стандартом стояли гранды индустрии (Microsoft, IBM, Sun) — вам следует остановить свой выбор на SOAP;
  • если же данные являются относительно простыми, а приложения должны работать на множестве платформ и на разных языках, если важна скорость работы и логика системы не нуждается в сложных командах — используйте XML-RPC.

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

Если выберете XML-RPC — написать программу клиента/сервера не составит труда даже начинающему программисту. Да и о выборе ПО можете не задумываться — хоть Borland Delphi/Kylix, хоть Phyton. Но не все задачи будут решаться сразу, а некоторые не будут решаться вообще.

Не трудно увидеть, что стандарт XML-RPС очень прост — и в то же время применение XML как основного инструмента для описания данных позволяет сделать его очень гибким. Протокол можно модифицировать под каждую конкретную задачу, а использование хорошо зарекомендовавших себя стандартов на передачу данных (HTTP/HTTPS) позволяет успешно применять его на любых платформах, где имеется его поддержка.

xmlrpc_server_destroy — Уничтожает серверные ресурсы

(PHP 4 >= 4.1.0, PHP 5, PHP 7)

xmlrpc_server_destroy — Уничтожает серверные ресурсы

Описание

Эта функция является ЭКСПЕРИМЕНТАЛЬНОЙ. Поведение этой функции, ее имя и относящаяся к ней документация могут измениться в последующих версиях PHP без уведомления. Используйте эту функцию на свой страх и риск.

К настоящему времени эта функция еще не была документирована; для ознакомления доступен только список аргументов.

Что такое Xmlrpc.php для WordPress и как его отключить

Xmlrpc.php в WordPress используется для удаленного доступа к вашему сайту, через сторонние приложения. Данный инструмент появился, когда WordPress только зарождался и скорость интернета не позволяла быстро создавать и публиковать записи на сайт. Существовал офлайн-клиент, в котором администратор создавал и редактировал записи, а затем через xmlrpc.php записи публиковались на сайт.

В 2008 году было выпущено приложение WordPress для iPhone и поддержка XML-RPC была включена по умолчанию, без возможности отключить.

Зачем отключать xmlrpc.php?

Одна из важных причин, из-за которой стоит отключить XML-RPC — это угроза безопасности вашего сайта. Злоумышленники часто используют эту лазейку для взлома пароля от админки вашего сайта, а также для DDoS-атаки.

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

Проверить можно с помощью XML-RPC Validator. Для этого:

В поле Address введите ваш домен и нажмите Check:

Если вы получили сообщение «Congratulation! Your site passed the first check», то xmlrpc.php на вашем сайте включен.

Если ответ «Failed to check your site at http://domain.ru because of the following error», то xmlrpc.php отключен.

Чтобы отключить XML-RPC выберите нужную инструкцию:

Чтобы отключить XML-RPC, достаточно установить плагин Disable XML-RPC и активировать его. Он автоматически укажет необходимые настройки и закроет доступ через xmlrpc.php.

Установить плагин можно через админку WordPress, в разделе Плагины.

Если вы хотите сделать все вручную без установки плагина:

Откройте или создайте (если он отсутствует) файл .htaccess и вставьте в конце файла строки:

xmlrpc.server — Basic XML-RPC servers¶

The xmlrpc.server module is not secure against maliciously constructed data. If you need to parse untrusted or unauthenticated data see XML vulnerabilities .

Create a new server instance. This > SimpleXMLRPCRequestHandler . The addr and requestHandler parameters are passed to the socketserver.TCPServer constructor. If logRequests is true (the default), requests will be logged; setting this parameter to false will turn off logging. The allow_none and encoding parameters are passed on to xmlrpc.client and control the XML-RPC responses that will be returned from the server. The bind_and_activate parameter controls whether server_bind() and server_activate() are called immediately by the constructor; it defaults to true. Setting it to false allows code to manipulate the allow_reuse_address > loads() function and controls which types are processed when date/times values or binary data are received; it defaults to false.

Changed in version 3.3: The use_builtin_types flag was added.

Create a new instance to handle XML-RPC requests in a CGI environment. The allow_none and encoding parameters are passed on to xmlrpc.client and control the XML-RPC responses that will be returned from the server. The use_builtin_types parameter is passed to the loads() function and controls which types are processed when date/times values or binary data are received; it defaults to false.

Changed in version 3.3: The use_builtin_types flag was added.

Create a new request handler instance. This request handler supports POST requests and modifies logging so that the logRequests parameter to the SimpleXMLRPCServer constructor parameter is honored.

SimpleXMLRPCServer Objects¶

The SimpleXMLRPCServer > socketserver.TCPServer and provides a means of creating simple, stand alone XML-RPC servers.

SimpleXMLRPCServer. register_function ( function=None, name=None ) В¶

Register a function that can respond to XML-RPC requests. If name is given, it will be the method name associated with function, otherwise function.__name__ will be used. name is a string, and may contain characters not legal in Python identifiers, including the period character.

This method can also be used as a decorator. When used as a decorator, name can only be given as a keyword argument to register function under name. If no name is given, function.__name__ will be used.

Changed in version 3.7: register_function() can be used as a decorator.

Register an object which is used to expose method names which have not been registered using register_function() . If instance contains a _dispatch() method, it is called with the requested method name and the parameters from the request. Its API is def _dispatch(self, method, params) (note that params does not represent a variable argument list). If it calls an underlying function to perform its task, that function is called as func(*params) , expanding the parameter list. The return value from _dispatch() is returned to the client as the result. If instance does not have a _dispatch() method, it is searched for an attribute matching the name of the requested method.

If the optional allow_dotted_names argument is true and the instance does not have a _dispatch() method, then if the requested method name contains periods, each component of the method name is searched for individually, with the effect that a simple hierarchical search is performed. The value found from this search is then called with the parameters from the request, and the return value is passed back to the client.

Enabling the allow_dotted_names option allows intruders to access your module’s global variables and may allow intruders to execute arbitrary code on your machine. Only use this option on a secure, closed network.

Registers the XML-RPC introspection functions system.listMethods , system.methodHelp and system.methodSignature .

Registers the XML-RPC multicall function system.multicall.

An attribute value that must be a tuple listing val > (‘/’, ‘/RPC2’) .

SimpleXMLRPCServer Example¶

The following client code will call the methods made available by the preceding server:

register_function() can also be used as a decorator. The previous server example can register functions in a decorator way:

The following example included in the Lib/xmlrpc/server.py module shows a server allowing dotted names and registering a multicall function.

Enabling the allow_dotted_names option allows intruders to access your module’s global variables and may allow intruders to execute arbitrary code on your machine. Only use this example only within a secure, closed network.

This ExampleService demo can be invoked from the command line:

The client that interacts with the above server is included in Lib/xmlrpc/client.py :

This client which interacts with the demo XMLRPC server can be invoked as:

CGIXMLRPCRequestHandler¶

The CGIXMLRPCRequestHandler class can be used to handle XML-RPC requests sent to Python CGI scripts.

CGIXMLRPCRequestHandler. register_function ( function=None, name=None ) В¶

Register a function that can respond to XML-RPC requests. If name is given, it will be the method name associated with function, otherwise function.__name__ will be used. name is a string, and may contain characters not legal in Python identifiers, including the period character.

This method can also be used as a decorator. When used as a decorator, name can only be given as a keyword argument to register function under name. If no name is given, function.__name__ will be used.

Changed in version 3.7: register_function() can be used as a decorator.

Register an object which is used to expose method names which have not been registered using register_function() . If instance contains a _dispatch() method, it is called with the requested method name and the parameters from the request; the return value is returned to the client as the result. If instance does not have a _dispatch() method, it is searched for an attribute matching the name of the requested method; if the requested method name contains periods, each component of the method name is searched for individually, with the effect that a simple hierarchical search is performed. The value found from this search is then called with the parameters from the request, and the return value is passed back to the client.

Register the XML-RPC introspection functions system.listMethods , system.methodHelp and system.methodSignature .

Register the XML-RPC multicall function system.multicall .

CGIXMLRPCRequestHandler. handle_request ( request_text=None ) В¶

Handle an XML-RPC request. If request_text is given, it should be the POST data provided by the HTTP server, otherwise the contents of stdin will be used.

Documenting XMLRPC server¶

>xmlrpc.server. DocXMLRPCServer ( addr, requestHandler=DocXMLRPCRequestHandler, logRequests=True, allow_none=False, encoding=None, bind_and_activate=True, use_builtin_types=True ) В¶

Create a new server instance. All parameters have the same meaning as for SimpleXMLRPCServer ; requestHandler defaults to DocXMLRPCRequestHandler .

Changed in version 3.3: The use_builtin_types flag was added.

Create a new instance to handle XML-RPC requests in a CGI environment.

Create a new request handler instance. This request handler supports XML-RPC POST requests, documentation GET requests, and modifies logging so that the logRequests parameter to the DocXMLRPCServer constructor parameter is honored.

DocXMLRPCServer Objects¶

The DocXMLRPCServer > SimpleXMLRPCServer and provides a means of creating self-documenting, stand alone XML-RPC servers. HTTP POST requests are handled as XML-RPC method calls. HTTP GET requests are handled by generating pydoc-style HTML documentation. This allows a server to provide its own web-based documentation.

DocXMLRPCServer. set_server_title ( server_title ) В¶

Set the title used in the generated HTML documentation. This title will be used inside the HTML “title” element.

DocXMLRPCServer. set_server_name ( server_name ) В¶

Set the name used in the generated HTML documentation. This name will appear at the top of the generated documentation inside a “h1” element.

DocXMLRPCServer. set_server_documentation ( server_documentation ) В¶

Set the description used in the generated HTML documentation. This description will appear as a paragraph, below the server name, in the documentation.

DocCGIXMLRPCRequestHandler¶

The DocCGIXMLRPCRequestHandler > CGIXMLRPCRequestHandler and provides a means of creating self-documenting, XML-RPC CGI scripts. HTTP POST requests are handled as XML-RPC method calls. HTTP GET requests are handled by generating pydoc-style HTML documentation. This allows a server to provide its own web-based documentation.

DocCGIXMLRPCRequestHandler. set_server_title ( server_title ) В¶

Set the title used in the generated HTML documentation. This title will be used inside the HTML “title” element.

DocCGIXMLRPCRequestHandler. set_server_name ( server_name ) В¶

Set the name used in the generated HTML documentation. This name will appear at the top of the generated documentation inside a “h1” element.

DocCGIXMLRPCRequestHandler. set_server_documentation ( server_documentation ) В¶

Set the description used in the generated HTML documentation. This description will appear as a paragraph, below the server name, in the documentation.

Igorkam

Ярлыки

  • С++ (3)
  • Стихи (1)
  • тонировка (1)
  • Цитаты (2)
  • ALTlinux (1)
  • Apache (2)
  • big-endian (1)
  • Blogger (1)
  • books (3)
  • books links (1)
  • Buisness (10)
  • C (1)
  • C# (5)
  • c++ (27)
  • car (8)
  • Cheat (1)
  • CSS (1)
  • DLL (1)
  • Draw (1)
  • Eclipse (2)
  • Films (1)
  • Firefox (4)
  • Flash (1)
  • GTK (2)
  • GUI (1)
  • Home server (1)
  • Hotels (1)
  • HTML (6)
  • IE (1)
  • Internet (2)
  • Java (1)
  • JavaScript (6)
  • jQuery (1)
  • KDE (1)
  • KeeTouch (1)
  • Linux (34)
  • little-endian (1)
  • Makefile (1)
  • MFC (6)
  • multi-thread (2)
  • Music (1)
  • ODBC (2)
  • OpenBox (2)
  • photo (4)
  • PHP (38)
  • programing (2)
  • proxy (1)
  • QML (37)
  • Qt (41)
  • QtCreator (2)
  • RegExp (3)
  • Shopping (12)
  • shutdown (1)
  • Soft (1)
  • Sound Card (1)
  • SQL (1)
  • SQL Server (14)
  • Subversion (1)
  • SVN (1)
  • teach (4)
  • text-editor (1)
  • Travels (1)
  • Ubuntu (38)
  • Upstart (1)
  • Vi (2)
  • VirtualBox (2)
  • Virtualization (1)
  • vkontakte.ru (1)
  • Web (2)
  • Web-Kit (5)
  • WinAPI (7)
  • Windows (4)

понедельник, 17 января 2011 г.

PHP XML-RPC server

1. Определяем функции, которые будут доступны клиенту. Для примера напишем функцию сложения двух чисел:
Любая функция, регистрируемая на xml-rpc сервере, должна принимать 3 параметра:

$MethodName — внешнее имя функции;
$Params — массив параметров, передаваемых клиентом;
$AppData — дополнительные параметры, передаваемые при вызове функции xmlrpc_server_call_method().

2. Создаем XML-RPC сервер вызовом функции

3. Регистрируем на сервере, определенные ранее функции

xmlrpc_server_register_method($srv, «Add», «srvAdd»);

Здесь:
Add — внешнее имя функции srvAdd,
srv — handler сервера.

4. Получаем «сырой» запрос от клиента

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

$response = xmlrpc_server_call_method($srv, $xmlRequest, Null);

Здесь:
$srv — handler xml-rpc сервера;
$xmlRequest — данные от клиента в xml-формате;
Третий параметр, в данном случае пустой, передает дополнительные данные для определенных ранее функций (параметр $AppData).

6. Отдаем клиенту результаты работы функции

CodeIgniter XMLRPC Server — отсутствует элемент корневого элемента

Я конвертирую старую библиотеку xmlrpc в CI для использования в более крупном проекте, но в то время как старая библиотека работает, мое преобразование — нет.

Старая библиотека выглядит следующим образом:

В новую тестовую библиотеку я встроил контроллер следующим образом:

Когда запрос делается от клиента, он возвращает ошибку, в которой отсутствует элемент Root:

Не удается подключиться к серверу отчетов пользователей. Метод reportuser, параметры System.Collections.Hashtable. Исключение System.Xml.XmlException: отсутствует элемент Root.

Ни фактический запрос на ввод, ни тот, который используется для исходных входных данных, как представляется, выполняются, поэтому перед этим должен быть сбой кода, но я понятия не имею, почему. Документы CI не предоставляют много информации ни о том, почему это могло бы вызвать ошибку, единственное, что я мог найти, было в access.log сервера, показывающем: «POST/Report/reportuser/HTTP/1.1» 200 31 «-» «-«, хотя это означает, что он действительно не получает никаких данных или это нормально для xmlrpc. Я не знаю.

Есть ли что-то, что я пропустил или, может быть, ошибку в синтаксисе? Есть ли способ просто получить необработанные данные, чтобы я мог посмотреть на него, чтобы увидеть его формат?

Linux.yaroslavl.ru

Учебник РНР
Назад Вперёд

xmlrpc_server_destroy — разрушает ресурсы сервера.

Описание

void xmlrpc_server_destroy (resource server)

Эта функция — ЭКСПЕРИМЕНТАЛЬНАЯ. Поведение, имя и всё остальное, что задокументировано для данной функции может быть изменено в будущих релизах РНР без предупреждения. Вы можете использовать эту функцию только на свой страх и риск.

Предупреждение!

Эта функция в настоящее время ещё не задокументирована; имеется только список аргументов.

Илон Маск рекомендует:  table-layout в CSS
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
Предупреждение!