СОСТАВЛЕНИЕ ПРОТОКОЛА НТТР-АВТОРИНГА

Предшествующий уровень техники

На фиг.1 показано сообщение 50 протокола передачи гипертекста (HTTP). Обмен HTTP-сообщениями 50 между HTTP-клиентом 52 и HTTP-сервером 54 хорошо известен в технике обработки данных, выполняемой в системе сервер-клиент. Можно обратиться к различным документам RFC («рабочие предложения» по стандартам) и другим опубликованным документам по проводу деталей, касающихся различных версий и вариантов HTTP. Например, RFC 2616 определяет HTTP версии 1.1. В соответствии с RFC 2616 HTTP-сообщение 50, которое предназначено для HTTP-запроса, имеет строку 54 запроса, такую как “GET/HTTP/1.1” (получить HTTP версии 1.1). HTTP-сообщение 50, которое предназначено для HTTP-ответа, напротив, имеет строку 56 статуса, такую как “HTTP/1.1 200 OK”. За строкой запроса 54 и строкой 56 статуса обычно следуют один или более заголовков, каждый из которых состоит из имени 60 поля, и, в зависимости от конкретного заголовка, ноль или больше тел 62 поля. Сообщение 50 может заканчиваться телом 64 сообщения, в зависимости от типа запроса или ответа. Детали, относящиеся к разделителям, конкретным заголовкам и другим признакам HTTP-сообщений и HTTP-передач, могут быть найдены и в других местах.

На фиг.2 показан пример HTTP-запроса 80 и пример HTTP-ответа 82. HTTP-клиент 52 посылает запрос 80 по сети 84 передачи данных на HTTP-сервер 54, который обрабатывает запрос и возвращает ответ 82. Запрос 80 включает в себя строку 87 запроса и ряд заголовков 88 (некоторые запросы также имеют тело сообщения). Ответ 82 включает в себя строку 89 статуса, заголовки 90 и тело 92 сообщения. HTTP-передачи не обязательно должны проходить по сети, такой как сеть 84; возможен обмен данными между локальным клиентом и локальным сервером, хотя обычно через коммуникационные стеки локальной системы.

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

На фиг.3 показаны некоторые расширения 100 методов и расширения 102 заголовков протокола или расширение HTTP, которое добавляет дистанционную функциональность авторинга поверх HTTP. Эти расширения взяты из RFC 2518, где определены «HTTP-расширения для Web-авторинга и контроля версий» или «WebDAV». WebDAV является расширенной версией HTTP, которая иногда называется протоколом, а иногда называется расширением HTTP. WebDAV-протокол определяет соглашения, методы 100 и заголовки 102 для запросов и ответов, которые в остальном соответствуют HTTP. То есть WebDAV-запросы и ответы следуют базовому формату HTTP-сообщений (например, сообщения 50 на фиг.1). Технически некоторые из команд в методах 100 web-авторинга определены как действительные HTTP-команды, однако их функциональность расширена посредством WebDAV. Например, команда PUT («поместить») является частью HTTP, но WebDAV расширяет ее функциональность до коллекций, каталогов, папок и т.д. Используются те же самые базовые правила HTTP-коммуникаций, используются те же самые ограничители строка/поле/тело, могут использоваться те же самые коды ошибок и базовые HTTP-методы 104 и базовые HTTP-заголовки могут появляться в WebDAV-сообщениях. Например, на обычный HTTP-запрос OPTIONS («опции») WebDAV-совместимый сервер может отвечать ответом, который имеет стандартные HTTP-заголовки, а также один или более нестандартных HTTP-заголовков, которые указывают на доступность одного или более HTTP-расширений на сервере. В принципе, этот способ расширения HTTP позволяет серверам и клиентам манипулировать как базовыми HTTP-коммуникациями, так и их различными расширениями, даже если удаленная система не поддерживает расширение, которое поддерживается локальным образом; неподдерживаемые заголовки и методы обычно игнорируются или обрабатываются постепенно.

WebDAV-расширение для HTTP предоставляет функциональность для создания, изменения и перемещения документов на удаленный сервер (в типовом случае web-сервер). WebDAV-реализации полезны, в числе прочего, для удаленного авторинга документов или ресурсов, обслуживаемых web-сервером. WebDAV-реализации могут также использоваться для общедоступного хранения основанных на Интернет-технологии файлов. Многие операционные системы, такие как Windows, Linux и Mac OSX предоставляют встроенную клиентскую и серверную поддержку для WebDAV, таким образом, предоставляя возможность использования файлов на WebDAV-сервере в некотором смысле подобно тому, как если бы они были сохранены в локальном каталоге.

Методы и заголовки WebDAV полностью документированы в разных местах, однако основные методы включают следующее: PUT - поместить ресурс или коллекцию на сервер; DELETE - удалить ресурс или коллекцию с сервера; PROPFIND - извлечь свойства (как XML) ресурса; PROPPATCH - изменить или удалить свойства ресурса; MKCOL - создать коллекции или каталоги; COPY - копировать ресурс с одного URI на другой на сервере; MOVE - переместить ресурс с одного URI на другой на сервере; LOCK - поместить блокировку на ресурс; UNLOCK - удалить блокировку с ресурса. Некоторыми примечательными заголовками (именами полей) являются: destination - определяет ресурс места назначения для методов, таких как COPY и MOVE; Lock-Token - определяет маркер, который идентифицирует конкретную блокировку; и Timeout - определяет продолжительность блокировки.

Недавно было выявлено, что имеются некоторые неэффективности и слабые места в рамках WebDAV, которые могут стать заметными при определенных обстоятельствах. Фиг.4 показывает временную диаграмму для последовательности связанных запросов авторинга. Предположим, что пользователь HTTP-клиента 52 хотел бы получить и блокировать ресурс на HTTP-сервере 54. Пользователь будет сначала управлять клиентом 52 для получения конкретного ресурса. Клиент 52 будет генерировать и передавать запрос 120 GET на сервер 54. Сервер 54 обрабатывает запрос 120 GET и возвращает соответствующий ответ 122. Время на двустороннее прохождение представляет собой время между моментами, когда клиент 52 передает запрос 120 GET и принимает ответ 122. Как показано на фиг.4, большая часть из времени на двустороннее прохождение может относиться к времени, которое требуется для того, чтобы запрос 120 GET и ответ 122 пересекли сеть. Если пользователю также требуется блокировать ресурс, полученный путем запроса 120 GET, необходим другой цикл информационного обмена: клиент 52 посылает отдельный запрос 124 LOCK; запрос 124 LOCK проходит через сеть; и сервер 54 реагирует ответом 126, который также пересекает сеть. Второй информационный обмен имеет свое собственное время на двустороннее прохождение, которое может включать в себя значительное время передачи по сети. Полное время 128, для того чтобы удовлетворить две связанные потребности клиента 52 (необходимость как получить, так и блокировать ресурс), включает в себя время двух двусторонних прохождений или четырех сетевых передач. Кроме того, два отдельных запроса 120, 124 требуют примерно двойной служебной нагрузки сервера по сравнению с одним запросом, что может вызвать дополнительную задержку, если сервер сильно загружен.

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

Элементарная природа WebDAV и неспособность WebDAV-клиентов и серверов использовать составные или многоаспектные запросы авторинга с одним дискретным обменом могут иметь другие проблемы и неудобства. Без необходимости, некоторые варианты осуществления, обсужденные ниже, могут смягчить некоторые проблемы, ассоциированные с HTTP-авторингом.

Сущность изобретения

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

Некоторые соглашения по информационному обмену между клиентом и сервером расширяют методы составного web-авторинга до протокола web-авторинга, такого как WebDAV. Более конкретно, запрос web-авторинга может быть снабжен специальной информацией заголовка для обозначения первого метода web-авторинга, объединенного со вторым методом web-авторинга, указанным командой в запросе. Клиенты и серверы снабжены методами для использования расширений web-авторинга. Расширенная обработка ошибок может быть использована, чтобы позволить серверам предоставлять более обогащенную информацию об ошибках web-авторинга клиентам.

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

Описание чертежей

Одинаковые ссылочные позиции использованы для обозначения одинаковых элементов на чертежах.

Фиг.1 - HTTP-сообщение.

Фиг.2 - пример HTTP-запроса и пример HTTP-ответа.

Фиг.3 - некоторые расширения методов и расширения заголовков протокола или расширения HTTP, которые добавляют дистанционную функциональность авторинга поверх HTTP.

Фиг.4 - временная диаграмма для последовательности связанных запросов авторинга.

Фиг.5 - некоторые расширения методов web-авторинга и составление расширений заголовков, которые могут быть использованы, чтобы позволить клиентам и серверам объединить два или более связанных методов авторинга в единые информационные обмены между клиентом и сервером.

Фиг.6 - информационный обмен несоставного авторинга и информационный обмен составного авторинга со сходным назначением.

Фиг.7 - иллюстрация того, каким образом клиент может определить, является ли доступным составление на сервере.

Фиг.8 - иллюстрация того, каким образом запросы могут быть форматированы для вызова составного блокирования.

Фиг.9 - механизм объединения методов свойств с методами или командами HTTP или WebDAV.

Фиг.10 - иллюстрация других составных методов.

Фиг.11 - пример запроса метода POSR+PROPFIND+LOCK и соответствующего ответа.

Фиг.12 - таблица обработки ошибок и примеры ответа с использованием расширенной обработки ошибок.

Детальное описание

Фиг.5 показывает некоторые расширения 140 методов web-авторинга и расширения 142 заголовков составления, которые могут быть использованы, чтобы позволить клиентам и серверам объединить два или более относящихся к авторингу методов в единые информационные обмены между клиентом и сервером. Хотя расширения 140 методов характеризуются как «методы», им не требуется использовать команды или строки 54 запроса, которые отличаются от тех, которые определены посредством HTTP или WebDAV. Однако концептуально расширения 140 методов, обсужденные ниже, осуществляют составные методы авторинга. Как описано ниже, эти расширения 140 в действительности составных методов авторинга могут быть реализованы с использованием различных расширений 142 составных заголовков.

На чертежах символы “+” и “|” (вертикальная черта) соответственно обозначают составление (объединение) и «или». Так, например, метод 144 “POST|GET+LOCK|REFRESH|INLOCK” представляет ряд отдельных составных методов: “POST+LOCK”, “POST+UNLOCK”, “GET+LOCK” и т.д. Пояснение того, каким образом расширения 140 методов могут быть реализованы с использованием расширений 142 заголовков, представлено ниже. Методы 144 и 146 обсуждаются со ссылкой на фиг.8. Методы 148 и 150 обсуждаются со ссылкой на фиг.9. Методы 152 и 154 обсуждаются со ссылкой на фиг.10 и 11.

Фиг.6 показывает информационный обмен несоставного авторинга и информационный обмен составного авторинга со сходным назначением. Левая сторона фиг.6 - повторение фиг.4 - показывает поток информационного обмена несоставного авторинга. Правая сторона фиг.6 показывает поток информационного обмена составного авторинга. На правой стороне фиг.6 (составной пример) одиночное сообщение 170 запроса посылается клиентом 52. Сообщение 170 запроса включает в себя информацию, указывающую операцию GET, направленную на ресурс на сервере 174, и информацию, указывающую, что сервер 174 должен также блокировать ресурс для клиента 172. В составном случае, имеет место только один информационный обмен со временем, равным времени одного двустороннего прохождения. Полное время 174 транзакции для составного запроса 170 меньше, чем полное время 120 транзакции несоставных запросов 120, 124. Более того, поскольку сервер 174 может сообщить из сообщения 170 запроса, что желательна блокировка, сервер 174 может немедленно блокировать запрошенный ресурс, таким образом, препятствуя помехам запросу клиента 172 от промежуточного запроса.

На фиг.7 показано, каким образом клиент 172 может определить, доступно ли составление на сервере 174. Как отмечено ранее, желательно (но не обязательно), чтобы клиент мог использовать как составные, так и несоставные запросы авторинга. Также желательно, чтобы сервер мог поддерживать как составные, так и несоставные запросы авторинга. Для этой цели может быть предоставлен некоторый механизм. Предпочтительно, этот механизм предусматривает включение информации в ответ сервера, который указывает, поддерживается ли упомянутое составление сервером. Хотя эта информация может принимать любую форму, использование нового заголовка 190 ответа является удобным, поскольку клиенты обычно игнорируют нераспознанные заголовки в HTTP-ответе. Кроме того, известные алгоритмы для анализа заголовков могут быть легко расширены на процесс для нового заголовка или имени поля. В альтернативном варианте, указатель составления может принимать форму нового значения для стандартного заголовка, специальной строки статуса и т.д.

Для установления доступности составления, клиент 172 выполняет процесс 192, который начинается с посылки стандартного запроса 194 OPTIONS (запрос 194 является лишь одним примером). Процесс 196 на сервере 174 принимает запрос 194 OPTIONS и генерирует ответ такой, как ответ 198, который включает в себя указатель составления, в данном варианте нестандартный заголовок 190 ответа. Действительное имя нестандартного заголовка 190 ответа не является важным, за исключением того, что он должен быть известным заранее для клиента 172, так что когда процесс 192 клиента 172 получает ответ 198, он может распознать его и осуществлять информационный обмен с сервером 174 надлежащим образом.

На фиг.8 показано, каким образом запросы могут форматироваться, чтобы вызвать составное блокирование. Верхняя часть соответствует расширенным методам 144 (см. фиг.5) для блокирования GET и POST, а нижняя часть соответствует расширенным методам 146 для блокирования PUT. В одном варианте осуществления обычные команды 220 HTTP и WebDAV-запросов GET, POST и PUT соединяются с запросами блокирования с использованием различных комбинаций стандартного заголовка 222 Lock-Token и нестандартного или расширенного заголовка 224 lock timeout, например, “X-MSDAVEXTLock-Timeout”. Заголовок 224 lock timeout имеет значение 0 или несколько секунд.

Заголовок 224 lock timeout обозначает создание новой блокировки в соответствии со значением заголовка 224 lock timeout. Если заголовок 222 Lock-Token включен, то заголовок 224 lock timeout сигнализирует обновление существующего блокирования. Если заголовок 224 lock timeout установлен на 0 секунд, то указывается деблокирование (в этом случае заголовок 222 Lock-Token и корректный маркер требуются для деблокирования файла). Кроме того, заголовок 222 Lock-Token и маркер предпочтительно включены в ответ на операцию записи блокированного ресурса. Примерный запрос 228 показывает, что типовой запрос POST+UNLOCK может выглядеть подобным образом. Отметим включение заголовка 222 Lock-Token и заголовка 224 lock timeout.

Обращаясь к команде PUT, объединенной с операцией блокирования, отметим, что заголовок 222 Lock-Token и корректный маркер необходимы для модифицирования блокированного ресурса. Никакого маркера не требуется, если ресурс не блокирован. Если никакой маркер не включен, но время блокирования определено, то возникает естественная логика блокирования; блокирование предоставляется, если блокирование не существует, и PUT, и блокирование отклоняются, если блокирование уже существует. В итоге, если корректный маркер включен в запрос PUT, клиент может выполнять любую операцию PUT, или любую операцию PUT, объединенную с операцией блокирования. Типовой запрос PUT+REFRESH показан запросом 230. Значение lock timeout 120 секунд указывает обновление или переустановку времени жизни блокирования для выполнения в течение еще 120 секунд, и маркер блокирования является ключом, который сервер использует для авторизации как операции PUT, так и операции REFRESH. В предпочтительном варианте заголовок Lock-Token, включенный в операцию «не записывать», игнорируется, то есть “GET+проверить существующее блокирование” не поддерживается.

На фиг.9 показан механизм объединения методов свойств с методами или командами HTTP или WebDAV. Эти составные методы соответствуют методам 148, 150 на фиг.5. Составные методы свойств используют два указателя; значение 240 специального заголовка типа контента (например, “multipart/ MSDAVEXTPrefixEncoded”) и специальный заголовок 242 расширений с различными возможными значениями, такой как “PROPFIND” и “PROPPATCH”. Комбинации в таблице 244 не требуют дополнительного объяснения, и результирующие методы разрешают доступ к ресурсу или его модифицирование при одновременном получении или установке одного или более свойств релевантного ресурса. Кроме того, стандартный заголовок Content-length («длина контента») будет использоваться и будет давать значение всего тела сообщения или полезной нагрузки, что также может включать свойства, а также ресурсы (дополнительно обсуждено ниже).

В соответствии с правилами таблицы 244, показан пример запроса 246 GET+PROPFIND. Отметим включение указания части PROPFIND метода в форме специального заголовка 242 расширений с соответствующим значением или командой.

Хотя в одном варианте осуществления связанные со свойствами методы объединяются в другие методы с использованием заголовков и расширения тела сообщения, также могут использоваться другие подходы. Например, методы WebDAV PROPFIND и PROPPATCH могут быть перегружены с использованием новых заголовков. Кроме того, имеются разные пути для объединения ресурса и набора свойств в теле сообщения. Все из свойств могут быть помещены в отдельные заголовки, поскольку большинство наборов свойств имеют поддающийся управлению размер. Свойства могут быть назначены соответствующим различным заголовкам, хотя это потребовало бы большего кодирования для обработки транспорта свойств. В другом варианте осуществления все свойства (XML-структура) могут быть помещены в один большой заголовок, однако заголовки могут потенциально стать больше, чем буферы, которые некоторые web-серверы выделяют для обработки заголовков.

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

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

На фиг.9 также показан пример ответа 250 GET+PROPFIND. Отметим, что поле 240 заголовка типа контента сигнализирует наличие тела сообщения из множества частей с использованием специального расширения “multipart/MSDAVEXTPrefixEncodedheader”. Относящаяся к блокированию информация не требуется для метода PUT+PROPPATCH, но может обозначать наличие блокирования серверной стороны. Поле 240 заголовка типа контента обозначает наличие тела 248 сообщения из множества частей в теле 64 сообщения. В принципе, эти многие части разделены полем длины, за которым следуют соответствующие данные, иными словами, тело 64 сообщения несет один или более участков дискретных данных, каждому из которых предшествует соответствующий указатель длины. Размеры полей длины и размеры их данных добавляются к стандартному заголовку Content-length («длина контента»). Примерный ответ 250 на фиг.9 имеет секцию properties («свойства») и секцию resource («ресурс»), каждому из которых предшествует соответствующее поле длины, например, 64-битовое целое число. Поскольку составной авторинг проектируется как HTTP-расширение, то используется стандартное тело 64 HTTP-сообщения. Поскольку может потребоваться, чтобы свойствами можно было обмениваться в сообщении, которое также может включать в себя ресурс, такой как HTML-документ, образование пары «длина-данные» позволяет переносить как свойства, так и ресурсы в одном и том же теле 64 сообщения. Стандартный заголовок Content-length («длина контента») дает полную длину тела 64/248 сообщения и может использоваться, совместно с указателями длины, для анализа существенных частей контента в теле 248 сообщения.

Методы 152, 154 на фиг.5 (POST|GET+PROPFIND+LOCK|REFRESH|UNLOCK, PUT+PROPPATCH+LOCK|REFRESH|UNLOCK) могут быть реализованы путем объединения расширений свойств и блокирования, описанных выше. Поскольку функциональность блокирования и функциональность свойств логически разделены, методы и заголовки, описанные выше, могут легко сосуществовать в сообщении. Фиг.10 показывает другие составные методы. Верхнее сообщение является примером запроса 270 PUT+PROPPATCH+UNLOCK. Отметим, что размер тела, включая размер полей длины, равен 114234. Нижнее сообщение является примером соответствующего ответа 272. Ответ, который является успешным, не отличается от ответа на нормальный запрос PUT. Отсутствие заголовка lock token («маркер блокирования») обозначает успешное деблокирование. Фиг.11 показывает пример запроса 290 метода POST+PROPFIND+LOCK и соответствующий ответ 292. Запрос 290 побуждает сервер поместить ресурс или файл, установить некоторые свойства и деблокировать файл или ресурс.

Фиг.12 показывает таблицу обработки ошибок и примеры ответа 302 с использованием расширенной обработки ошибок. Ряд типов ошибок может возникать при создании ресурса на сервере посредством запроса расширенного HTTP-авторинга, например, недостаточные разрешения, ресурс, контролируемый другим пользователем или не контролируемый совсем, нарушение квоты, или блокированное имя файла или тип файла, наличие вируса и т.д. Другие ошибки, такие как пропуск свойства, могут возникнуть при попытке записи в файл или ресурс. Если ошибка авторинга возникает на сервере, то в типовом случае сервер может иметь обширную информацию системного уровня об ошибке. Ранее, когда модуль или сервер, который реализует методы WebDAV, обнаруживал ошибку, он должен был транслировать эту ошибку в стандартный HTTP-код ошибки. Клиент может пытаться обеспечить полезное сообщение о коде ошибки, возможно, с использованием соответствующей постоянно кодированной строки сообщения. Однако стандартные HTTP-коды ошибок не достаточно разнообразны, чтобы поддерживать количество и типы ошибок, которые пользователь может обнаружить с использованием расширенного HTTP-авторинга. Поэтому факультативно предоставляется расширение для расширения информации об ошибках, возвращаемой клиенту, при сохранении существующего HTTP-кода ошибки, что обеспечивает обратную совместимость. Эта расширенная обработка ошибок выполняется путем включения в ответы информации, специфической для ошибок системного уровня на сервере.

Как можно видеть на фиг.12, расширенная обработка ошибок может быть реализована с использованием нового HTTP-заголовка, например “X-MSDAVEXT_ERROR: Decimal; String”. Часть Decimal является кодом, который отображает ошибку системного уровня, такую как ошибка управления Unix-файла или ошибка Win32. Предпочтительно часть String имеет формат UTF-8.

Рассматривая расширения составления протоколов web-авторинга в общем, следует отметить, что некоторые серверы-посредники могут пытаться интерпретировать запросы и возвращать кэшированные ответы. Поэтому предпочтительно, чтобы клиенты использовали новые расширения или методы только с POST, но не GET. Кроме того, при ответе на конкатенированный метод или команду, как описано выше, сервер должен маркировать ответ, чтобы указать, что он не должен кэшироваться, с использованием, например, заголовка, подобного “cache-control: private” («кэш-управление: приватное»).

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

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

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

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

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

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

Все из вариантов осуществления и признаков, описанных выше, могут быть реализованы в форме информации, сохраненной на энергозависимом или энергонезависимом носителе, считываемом компьютером или устройством. Это включает, по меньшей мере, носители, такие как ПЗУ на компакт-диске (CD-ROM), магнитные носители, флэш-ПЗУ и т.д., хранящие машиноисполняемые инструкции или исходный код, или любую другую информацию, которая может использоваться для того, чтобы обеспечить возможность вычислительному устройству выполнить различные варианты осуществления. Сюда также должна включаться, по меньшей мере, энергозависимая память, такая как ОЗУ, хранящее информацию, такую как инструкции центрального процессора (CPU), в течение выполнения программы, выполняющей вариант осуществления.