Web Map Server Implementation Specification
Базовые элементы сервиса
Введение
В данном разделе рассматриваются аспекты работы Web Map Server, не зависящие от конкретных операций или являющиеся общими для различных операций.
Нумерация версий и их согласование
Нумерация версий
Web Map Service (WMS) определяет номер версии протокола. Данный номер применяется к XML-схеме и способу кодирования запросов, рассматриваемых в рамках данного Международного Стандарта. Номер версии состоит из трёх неотрицательных целых чисел, разделенных точкой, в формате "x.y.z". Числа "y" и "z" не должны превышать 99.
Изменение номера версии
Каждая последующая ревизия данного Международного Стандарта приводит к смене номера версии протокола. Нумерация возрастает монотонно и включает в себя не более трех целых чисел, разделенных точками, причем первое число является наиболее значимым. В числовой последовательности могут быть разрывы. Некоторые числа могут обозначать черновые версии. Серверы и их клиенты не должны поддерживать все существующие версии, но должны придерживаться правил согласования версий, описанных ниже.
Отображение в запросе и в метаданных сервиса
Номер версии должен отображаться как минимум в двух местах: в метаданных сервиса и среди списка параметров запроса клиента. Номер версии, указанный в запросе клиента к конкретному серверу, должен совпадать с номером версии, поддержку которой заявляет данный сервер (за исключением процесса согласования версий, описанного ниже). Сервер может поддерживать несколько версий, значения которых клиент также может получить согласно правилам согласования версий.
Согласование версий
WMS-клиент может согласовать с сервером номер взаимоприемлемой версии протокола. Согласование осуществляется посредством использования операции GetCapabilities (описываемой в 7.2) согласно следующим правилам.
Все метаданные сервиса должны включать номер версии протокола и должны соответствовать XML DTD или определению Схемы для данной версии. В ответ на запрос GetCapabilities (для которого параметр VERSION опционален) в котором не указан номер версии, сервер должен вернуть ответ, содержащий номер самой последней версии, которую он поддерживает. В ответ на запрос GetCapabilities, содержащий номер версии, сервер возвращает номер этой версии в случае если он ее поддерживает. Если же сервер не поддерживает указанную в запросе версию, то он передает клиенту информацию о поддерживаемой версии согласно следующим правилам:
- Если запрашиваемая версия не поддерживается сервером и при этом ее номер выше, чем номер самой низкой версии, поддерживаемой сервером, то в этом случае сервер сообщает клиенту самую последнюю версию, которую он поддерживает, причём номер этой версии будет всегда ниже номера запрошенной клиентом версии.
- Если запрашиваемая версия ниже чем любая версия, поддерживаемая сервером, то в этом случае сервер должен сообщить клиенту о самой низкой версии, которую он поддерживает.
- Если клиент не поддерживает версию, переданную сервером, то он может либо прекратить связь с сервером, либо выполнить новый запрос, указав другую версию.
Данный процесс может продолжаться до тех пор, пока взаимное соглашение насчет используемой версии не будет достигнуто или пока клиент не примет решение, что он не может или не будет взаимодействовать с конкретным сервером.
ПРИМЕР 1 Сервер поддерживает версии 1, 2, 4, 5 и 8. Клиент поддерживает версии 1, 3, 4, 6 и 7. Клиент запрашивает версию 7. Сервер отвечает версией 5. Клиент запрашивает версию 4. Сервер отвечает версией 4, которую понимает клиент. На этом процесс согласования версий успешно завершается.
ПРИМЕР 2 Сервер поддерживает версии 4, 5 и 8. Клиент поддерживает версию 3. Клиент запрашивает версию 3. Сервер отвечает версией 4. Клиент не поддерживает ни данную версию, ни какую-либо другую боле высокую. На этом процесс согласования версий завершается и клиент разрывает связь с сервером.
Параметр VERSION является обязательным во всех запросах за исключением GetCapabilities.
Общие правила HTTP-запросов
Введение
Данный Международный Стандарт определяет реализацию WMS на распределённой вычислительной платформе (distributed computing platform, DCP), включающей в себя Интернет-хосты, поддерживающие протокол HTTP (Hypertext Transfer Protocol) (см. IETF RFC 2616). Таким образом онлайн ресурс, соответствующий каждой операции, поддерживаемой сервером, определяется посредством HTTP URL (Uniform Resource Locator). URL может отличаться для каждой операции, или быть одинаковым, по усмотрению поставщика услуг. Каждый URL должен соответствовать как минимум требованиям IETF RFC 2616 (раздел 3.2.2 "HTTP URL"), а в остальном определяться той или иной реализацией; в данном Международном Стандарте рассматривается только та часть URL, которая отвечает за запросы к ресурсам сервиса.
HTTP поддерживает два типа запросов: GET и POST. Оба этих метода могут быть использованы для доступа к сервису, при этом URL запрашиваемого ресурса в каждом случае будет различным. Поддержка сервером GET-запросов - обязательна, POST-запросов - опциональна.
Зарезервированные символы в HTTP GET URL
В рамках спецификации URL (IETF RFC 2396) определяется список зарезервированных символов, требующих экранирования во избежания конфликтов. Некоторые символы из данного списка явным образом зарезервированы в рамках рассматриваемого Международного Стандарта для использования в WMS-запросах. В случае если символы "?", "&", "=", "," или "+" выполняют одну из ролей, указанных в Таблице 1, то они отражаются в URL в неизменном виде. В случае же если эти символы появляются где-либо еще (например, среди значений параметров), то они должны быть закодированы согласно IETF RFC 2396.
Сервер должен быть готов декодировать любой символ, закодированный таким способом, а также преобразовывать символ "+" в пробел.
| Символ | Роль |
| ? | Разделитель, сигнализирующий о начале строки запроса. |
| & | Разделитель между параметрами в строке запроса. |
| = | Разделитель между именем и значением параметра запроса. |
| , | Разделитель между значениями в списочных параметрах (таких как BBOX, LAYERS STYLES в запросах GetMap). |
| + | Сокращенное представление пробела. |
HTTP GET
WMS предполагает обязательную поддержку GET-запросов (IETF RFC 2616).
URL ресурса, к которому происходит обращение посредством GET-запроса, фактически представляет собой некоторую, специальным образом сконструированную строку (префикс), дополняемую служебными параметрами, отвечающими за запрос. Структура префикса определяется в соответствии с IETF RFC 2396 как строка, состоящая из названия схемы ("http" или "https"), имени или цифрового представления хоста, номера порта (опционально), пути, обязательного символа вопроса "?" и опциональной строки, содержащей один или более сервер-специфичных параметров, заканчивающихся символом амперсанда "&". Префикс определяет сетевой адрес, по которому будет отправлен запрос на конкретный сервер. Для различных операций может быть использован различный префикс. Выбор префикса определяется поставщиком услуг.
В рамках данного Международного Стандарта рассматривается способ построения второй части URL (query part), следующей за префиксом, необходимой для формирования полноценного запроса. Каждый тип WMS-запроса имеет собственный набор обязательных и опциональных параметров. Каждый параметр имеет собственное имя и может принимать одно или несколько допустимых значений, которые определяются либо в рамках данного Международного Стандарта, либо устанавливаются клиентом на основе метаданных сервиса. В процессе формирования второй части URL запроса клиентское приложение дополняет префикс обязательными и опциональными параметрами в формате "имя=значение&" (имя параметра, знак равенства, значение параметра, амперсанд). Символ "&" служит разделителем между парами имя/значение и поэтому является опциональным после последней пары в строке URL.
При использовании HTTP-метода GET, префикс URL, опрделяемый сервером, дополняется строкой запроса и результирующий URL используется как описано в спецификации HTTP (IETF RFC 2616).
В Таблице 2 представлена структура WMS-запроса при использовании HTTP-метода GET.
| Компонент URL | Роль |
| http://host[:port]/path[?{name[=value]&}] | Префикс URL. [ ] обозначает 0 или 1 повторение опциональной части; {} обозначает 0 или более повторений. |
| name=value& | Один или несколько стандартных параметров, определенных для каждого типа WMS-запроса в рамках данного Международного Стандарта. |
HTTP POST
WMS опционально может поддерживать "POST"-запросы (IETF RFC 2616).
URL ресурса при осуществлении POST-запроса - это полноценный URL (а не только префикс, как в случае с GET-запросом), что является допустимым в соответствии с IETF RFC 2396. В данном случае клиент передаёт параметры запроса в теле POST-сообщения. WMS не требует указания дополнительных параметров в URL для формирования валидного запроса. Тело POST-сообщения представляет собой XML-документ.
Общие правила формирования HTTP-ответов
При поступлении на сервер валидного запроса, сервер должен вернуть ответ, сформированный по правилам, описанным в Разделе 7 данного Международного Стандарта или вернуть исключение, сообщающее о невозможности сформировать корректный ответ. Только в случае процедуры согласования версий (см. 6.2.4) сервер может предлагать различный результат. При поступлении невалидного запроса сервер выдаёт исключение, как описано в 6.11.
Сервер может отправить HTTP-сообщение о перенаправлении (используя HTTP-коды как описано в IETF RFC 2616) запроса на другой URL, отличный от того, который был запрошен клиентом. Перенаправление предполагает, что клиент должен выполнить новый HTTP-запрос по новому URL. Теоретически, перенаправление может осуществляться несколько раз. Практически, последовательность перенаправлений заканчивается в момент, когда сервер возвращает WMS-ответ. Этот ответ должен соответствовать оригинальному запросу, посланному клиентом (или представлять собой исключение).
Ответ должен сопровождаться соответствующим HTTP-заголовком, содержащим MIME (Multipurpose Internet Mail Extensions) тип ответа (IETF RFC 2045). Список MIME-типов, используемых в Интернет, поддерживается организацией Internet Assigned Numbers Authority (IANA) [2]. Допустимые типы ответов и исключений рассмотрены ниже. Базовая структура MIME-типа представляет собой строку вида "тип/подтип". MIME допускает использование дополнительных параметров: "тип/подтип; параметр1=значение1; параметр2=значение2". Сервер может включать параметрезированные MIME-типы в собственный список поддерживаемых выходных форматов. В дополнение к любому параметризированному варианту сервер должен предлагать базовую непараметризированную версию.
Ответ должен сопровождаться другими HTTP-заголовками по мере необходимости и по мере возможности. В частности, заголовки Expires и Last-Modified содержат важную информацию для кэширования; Content-Length может использоваться клиентом для определения момента завершения передачи данных и эффективного распределения места под них; Content-Encoding и Content-Transfer-Encoding - для правильной интерпретации ответа.
Числовые и Логические значения
Целые числа должны быть представлены согласно спецификации целых типов данных, описанной в документе XML Schema Datatypes ([8], раздел 3.3.13). Данный Международный Стандарт обязан явным образом указывать где целое значение является обязательным.
Действительные числа должны быть представлены согласно спецификации чисел двойной точности, описанной в документе XML Schema Datatypes ([8], раздел 3.2.5). Это представление допустимо для целых, десятичных и экспоненциальных нотаций. Действительные значения допустимы во всех местах, определённых данным Международным Стандартом, за исключением тех, для которых явно указано использование целых чисел.
Положительные, отрицательные и нулевые значения также допустимы, если не оговорено обратное.
Логические значения должны быть представлены согласно спецификации логических значений, описанной в XML Schema Datatypes ([8], раздел 3.2.2). Значения "0" и "false" - эквивалентны. Значения "1" и "true" - эквивалентны. Данный Международный Стандарт явным образом указывает где логический тип является обязательным.