СПОСОБ ДОСТУПА К ВЕБ-УЗЛАМ, УСТРОЙСТВО И СИСТЕМА ВЕБ-УЗЛА Российский патент 2018 года по МПК G06F17/22 G06F17/30 

Область техники, к которой относится изобретение

[0001] Настоящее изобретение относится к области техники информационных технологий, и в частности, к способу доступа к веб-узлам, к устройству и к системе веб-узла.

Уровень техники

[0002] Всемирная паутина (World Wide Web, WWW) возникла в 1989 году и использует структуру "браузер-сервер". За счет использования Всемирной паутины, пользователь может осуществлять доступ, посредством использования веб-браузера, к разнообразным информационным ресурсам, предоставленным на веб-сервере. Обычно, файлы на веб-сервере сохраняются в файловой системе на веб-сервере. Веб-сервер преобразует, посредством использования организационной структуры, в которой универсальный указатель ресурса (Uniform Resoure Locator, URL-адрес) соответствует имени файла, URL-адрес, принимаемый из веб-браузера, в файл в локальной файловой системе. Например, серверное программное обеспечение задается на веб-сервере для веб-узла "example.funnycorp.com", и корневой каталог веб-серверного программного обеспечения задается как "/home/public/web/". После того, как пользователь вводит URL-адрес http://example.funnycorp.com/lips/raspberry.html в веб-браузере, веб-браузер отправляет запрос по протоколу передачи гипертекста (по протоколу передачи гипертекста, HTTP) на веб-сервер, и веб-сервер в "example.funnycorp.com" принимает HTTP-запрос и считывает файл "/home/public/web/lips/raspberry.html". Файл переносится в HTTP-ответе, с тем чтобы возвращаться в веб-браузер. HTTP-ответ, в общем, включает в себя файл на языке разметки гипертекста (на языке разметки гипертекста, HTML) и также может включать в себя текстовый файл, изображение или файл другого типа. После загрузки статического файла ресурсов, веб-браузер кэширует загружаемый статический файл ресурсов в локальной временной папке. Когда браузер должен осуществлять доступ к этому веб-узлу снова, браузер непосредственно считывает статический файл ресурсов из кэша, вместо загрузки снова, из веб-сервера, соответствующего веб-узлу, статического файла ресурсов, который уже кэширован, за счет этого ускоряя доступ к веб-узлу. Тем не менее, файл на веб-сервере может обновляться при обновлении веб-узла, и ввиду этого требуется механизм для того, чтобы обеспечивать то, что актуальный файл может получаться посредством браузера в ходе доступа к веб-узлу.

[0003] Механизм обновления файлов на основе хэша контента файла предоставляется в предшествующем уровне техники, чтобы обеспечивать динамическое обновление веб-страницы. В частности, URL-адрес, соответствующий файлу, хранимому на веб-сервере, представляет собой абсолютный путь. Например, формат абсолютного пути для файла logo.gif представляет собой "/directory/subdirectory/.../logo.gif". Когда веб-узел модернизируется, если файл logo.gif обновляется, имя файла изменяется на logo_hashcode.gif, причем хэш-код является хэш-значением, вычисленным на основе контента файла logo.gif. Каждый раз, когда изменяется контент файла, хэш-код повторно вычисляется. Соответственно, абсолютный путь изменяется на "/directory/subdirectory/.../logo_hashcode.gif", и браузер пользователя может получать актуальный файл logo.gif согласно этому абсолютному пути. Таким образом, реализуется динамическое обновление веб-страницы.

[0004] Тем не менее, файлы на веб-сервере имеют взаимные ссылки друг на друга. Когда другой файл ссылается на logo.gif, изменение имени файла logo.gif вызывает изменение контента файла для файла, который ссылается на logo.gif, и ввиду этого хэш-код файла, который ссылается на logo.gif, должно повторно вычисляться согласно измененному контенту файла. Например, файл a.js ссылается на logo.gif. Когда изменяется logo.gif, его имя файла изменяется на logo_hashcode.gif. В этом случае, контент файла для файла a.js изменяется соответствующим образом, и его имя файла изменяется на a_hashcode.js. Следовательно, в предшествующем уровне техники, когда один файл на веб-сервере обновляется, все файлы, зависимые от файла, обновляются соответствующим образом, что приводит к обновлению крупных файлов и увеличивает риски при модернизации веб-узлов.

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

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

[0006] Согласно одному аспекту, вариант осуществления этой заявки предоставляет способ доступа к веб-узлам, включающий в себя: прием запроса на доступ из клиента, причем запрос на доступ указывает страницу, к которой должен быть осуществлен доступ на веб-узле; получение начального универсального указателя ресурса (URL-адреса) файла контента, включенного в страницу, к которой должен быть осуществлен доступ, причем начальный URL-адрес включает в себя информацию исходного пути файла контента; получение параметра версии для текущей версии веб-узла, причем каждая версия веб-узла соответствует одной модернизации веб-узла, и каждая версия веб-узла соответствует уникальному параметру версии; формирование текущего URL-адреса файла контента согласно начальному URL-адресу файла контента и параметру версии для текущей версии веб-узла, причем текущий URL-адрес включает в себя часть информации пути и часть для поиска, часть информации пути включает в себя информацию исходного пути файла контента, и часть для поиска включает в себя параметр версии для текущей версии веб-узла; и возврат ответа по доступу в клиент, причем ответ по доступу переносит текущий URL-адрес файла контента.

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

[0008] В возможном проектном решении, система веб-узла дополнительно включает в себя сервер администрирования. При приеме обращения на запрос версии, отправленного посредством веб-сервера, сервер администрирования выполняет запрос относительно параметра версии согласно идентификатору веб-узла, переносимому в обращении на запрос версии, и возвращает параметр версии на веб-сервер. Сервер администрирования записывает идентификатор веб-узла, причем идентификатор может представлять собой идентификатор ключа веб-узла. Сервер администрирования дополнительно записывает номер текущей версии веб-узла и параметр версии, сформированный согласно номеру версии.

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

[0010] В возможном проектном решении, веб-сервер использует номер версии для текущей версии веб-узла в качестве параметра версии.

[0011] В возможном проектном решении, сервер администрирования может конфигурировать номер версии веб-узла любым из следующих способов: способ 1: когда версия веб-узла модернизируется, веб-сервер может записывать номер версии веб-узла после модернизации в файл описания версии, причем сервер администрирования извлекает номер последней версии веб-узла из файла описания версии; способ 2: веб-узел модернизируется специалистами по эксплуатации и обслуживанию, и после завершения модернизации, номер последней версии веб-узла записывается на сервер администрирования посредством использования интерфейса сервера администрирования; способ 3: веб-узел может модернизироваться посредством использования файла сценария модернизации, и система веб-узла дополнительно включает в себя модуль администрирования модернизации, причем модуль администрирования модернизации выполняет файл сценария модернизации, и после того как закончена модернизация веб-узла, и обновляется файл контента веб-узла, вызывается интерфейс сервера администрирования, и номер версии веб-узла конфигурируется на сервере администрирования; или способ 4: средство администрирования конфигурации системы веб-узла может отслеживать веб-сервер, и при обнаружении того, что версия веб-узла обновляется, считывать номер обновленной версии веб-узла из репозитория версий, вызывать интерфейс сервера администрирования и конфигурировать номер обновленной версии веб-узла на сервере администрирования. Эта заявка предоставляет вышеприведенные четыре способа для того, чтобы обеспечивать возможность серверу администрирования своевременно получать номер последней версии веб-узла и за счет этого формировать параметр версии, соответствующий номеру последней версии.

[0012] В возможном проектном решении, функция сервера администрирования реализуется в форме модуля администрирования на веб-сервере. В этом случае, веб-сервер может получать номер версии веб-узла, чтобы формировать параметр версии для текущей версии веб-узла, посредством использования способа, аналогичного вышеприведенным способам: способ 1: получение файла описания версии веб-узла и считывание номера версии для текущей версии веб-узла из файла описания версии; способ 2: прием номера версии для текущей версии веб-узла, которая записывается специалистами по эксплуатации и обслуживанию посредством использования интерфейса администрирования; способ 3: выполнение файла сценария модернизации, и после завершения модернизации веб-узла, конфигурирование номера версии для текущей версии веб-узла; или способ 4: отслеживание процесса модернизации версии веб-узла, и после того, как определяется завершение модернизации версии веб-узла, считывание номера версии для текущей версии веб-узла из репозитория версий.

[0013] В возможном проектном решении, начальный URL-адрес файла контента переносится в индексном файле, и веб-сервер заменяет начальный URL-адрес файла контента, включенного в индексный файл, на сформированный текущий URL-адрес и добавляет обновленный индексный файл в ответ по доступу.

[0014] В возможном проектном решении, сторона клиента кэширует имя файла и параметр версии файла контента, которые сохранен, когда клиент осуществлял доступ к веб-узлу до этого. Местоположение для кэширования может представлять собой клиент или другое устройство хранения данных, которое может соединяться с клиентом. Клиент выполняет запрос относительно кэшированного имени файла и параметра версии файла контента, чтобы определять то, кэширован или нет файл контента, включенный в страницу, к которой должен быть осуществлен доступ. Если да, кэшированный файл контента непосредственно считывается; если нет, сообщение с запросом файла инициируется на веб-сервер, чтобы получать файл контента из веб-сервера. Посредством настройки кэша, когда клиент-браузер осуществляет доступ к веб-узлу снова, если уже сохранен в кэше, файл контента, включенный в страницу, к которой должен быть осуществлен доступ, не должен обязательно снова получаться из веб-сервера. Это повышает эффективность доступа к веб-узлу.

[0015] В возможном проектном решении, веб-сервер может управлять атрибутом кэша файла контента на стороне клиента-браузера, и, в частности, веб-сервер добавляет в ответ по доступу параметр настройки кэша, который используется для того, чтобы указывать то, должна или нет сторона клиента-браузера кэшировать файл контента, и длительность кэширования.

[0016] В возможном проектном решении, веб-сервер определяет тип файла для индексного файла, переносимого в ответе по доступу, и определяет, согласно типу файла для индексного файла, то, включает или нет индексный файл в себя начальный URL-адрес файла контента. В частности, когда файл представляет собой CSS-файл или HTML-файл, индексный файл включает в себя начальный URL-адрес файла контента.

[0017] В возможном проектном решении, клиент-браузер может поддерживать AJAX-технологию и может получать файл контента из веб-сервера способом асинхронной передачи данных. В этом случае, файл cookie ответа по доступу переносит параметр версии для текущей версии веб-узла. Клиент считывает параметр версии предпочтительно из файла cookie, добавляет параметр версии в адрес запроса, сформированный на клиенте, файла контента, и получает файл контента из веб-сервера.

[0018] Согласно другому аспекту, вариант осуществления настоящего изобретения предоставляет другой способ доступа к веб-узлам. Способ осуществляется посредством прокси-сервера, посредством перехвата ответа по доступу, возвращаемого посредством веб-сервера, чтобы обновлять URL-адрес файла контента, переносимого в ответе по доступу. В частности, способ включает в себя: перехват первого ответа по доступу из веб-сервера, причем первый ответ по доступу отправляется после того, как веб-сервер принимает запрос на доступ из клиента, запрос на доступ указывает страницу, к которой должен быть осуществлен доступ на веб-узле, первый ответ по доступу переносит начальный URL-адрес файла контента, включенного в страницу, к которой должен быть осуществлен доступ, и начальный URL-адрес включает в себя информацию исходного пути файла контента; получение параметра версии для текущей версии веб-узла, причем каждая версия веб-узла соответствует одной модернизации веб-узла, и каждая версия веб-узла соответствует уникальному параметру версии; формирование текущего URL-адреса файла контента согласно начальному URL-адресу файла контента и параметру версии для текущей версии веб-узла, причем текущий URL-адрес включает в себя часть информации пути и часть для поиска, часть информации пути включает в себя информацию исходного пути файла контента, и часть для поиска включает в себя параметр версии для текущей версии веб-узла; и возврат второго ответа по доступу в клиент, причем второй ответ по доступу переносит текущий URL-адрес файла контента.

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

[0020] В возможном проектном решении, система веб-узла дополнительно включает в себя сервер администрирования. При приеме обращения на запрос версии, отправленного посредством прокси-сервера, сервер администрирования выполняет запрос относительно параметра версии согласно идентификатору веб-узла, переносимому в обращении на запрос версии, и возвращает параметр версии в прокси-сервер. Сервер администрирования записывает идентификатор веб-узла, причем идентификатор может представлять собой идентификатор ключа веб-узла. Сервер администрирования дополнительно записывает номер текущей версии веб-узла и параметр версии, сформированный согласно номеру версии.

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

[0022] В возможном проектном решении, прокси-сервер использует номер версии для текущей версии веб-узла в качестве параметра версии.

[0023] В возможном проектном решении, прокси-сервер может получать параметр версии для текущей версии веб-узла любым из следующих способов: способ 1: получение файла описания версии веб-узла и считывание номера версии для текущей версии веб-узла из файла описания версии; способ 2: прием номера версии для текущей версии веб-узла, которая записывается специалистами по эксплуатации и обслуживанию посредством использования интерфейса администрирования; способ 3: выполнение файла сценария модернизации, и после завершения модернизации веб-узла, конфигурирование номера версии для текущей версии веб-узла; или способ 4: отслеживание процесса модернизации версии веб-узла, и после того, как определяется завершение модернизации версии веб-узла, считывание номера версии для текущей версии веб-узла из репозитория версий.

[0024] В возможном проектном решении, начальный URL-адрес файла контента переносится в индексном файле в первом ответе по доступу, возвращаемом посредством веб-сервера, и прокси-сервер заменяет начальный URL-адрес файла контента, включенного в индексный файл, на сформированный текущий URL-адрес и добавляет обновленный индексный файл второй ответ по доступу, который отправляется в клиент.

[0025] В возможном проектном решении, второй ответ по доступу включает в себя параметр настройки кэша, который используется для того, чтобы указывать то, должен или нет клиент кэшировать файл контента, и длительность кэширования.

[0026] В возможном проектном решении, прокси-сервер дополнительно может определять тип файла для индексного файла, в первом ответе по доступу, соответствующий странице, к которой должен быть осуществлен доступ, и определяет, согласно типу файла для индексного файла, то, включает или нет индексный файл в себя начальный URL-адрес файла контента. Когда индексный файл представляет собой CSS-файл или HTML-файл, индексный файл включает в себя начальный URL-адрес файла контента.

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

[0028] В возможном проектном решении, функция прокси-сервера может быть интегрирована в существующий Nginx или HAProxy. Дополнительно, прокси-сервер может развертываться вместе с сервером администрирования или веб-сервером на одном физическом сервере. Когда прокси-сервер развертывается вместе с другим сервером, прокси-сервер может представлять собой один из функциональных модулей.

[0029] Согласно еще одному другому аспекту, вариант осуществления настоящего изобретения дополнительно предоставляет другой способ доступа к веб-узлам. Способ осуществляется посредством клиента и включает в себя: отправку запроса на доступ на веб-сервер, причем запрос на доступ указывает страницу, к которой должен быть осуществлен доступ на веб-узле; прием возвращаемого ответа по доступу, причем ответ по доступу переносит текущий URL-адрес файла контента, включенного в страницу, к которой должен быть осуществлен доступ, текущий URL-адрес включает в себя часть информации пути и часть для поиска, часть информации пути включает в себя информацию исходного пути файла контента, и часть для поиска включает в себя параметр версии для текущей версии веб-узла; и отправку сообщения с запросом файла на веб-сервер, с тем чтобы получать файл контента, причем сообщение с запросом файла переносит текущий URL-адрес файла контента.

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

[0031] В возможном проектном решении, клиент кэширует принимаемый файл контента и, в частности, сохраняет имя файла и параметр версии файла контента, которые получены, когда к веб-узлу осуществлен доступ до этого. При осуществлении доступа к веб-узлу, клиент определяет, согласно имени файла и параметру версии в текущем URL-адресе принимаемого файла контента, то, кэширован локально или нет файл контента. Если кэширован, файл контента не должен получаться из веб-сервера. Еще дополнительно, клиент может непосредственно сохранять текущий URL-адрес принимаемого файла контента, без различения параметра версии. Когда требуется выполнение запроса файла контента, URL-адрес, который должен быть получен, и сохраненный URL-адрес непосредственно сравниваются, чтобы определять то, уже кэширован локально или нет файл контента, соответствующий URL-адресу, который должен быть получен.

[0032] Клиент кэширует файл контента, принимаемый в предыдущем доступе, и записывает имя файла и параметр версии файла контента. При осуществлении доступа к странице веб-узла, после приема URL-адреса файла контента, включенного в страницу, к которой должен быть осуществлен доступ, клиент определяет то, уже кэширован локально или нет файл контента, соответствующий URL-адресу. После того, как веб-узел модернизируется, параметр версии для текущей версии веб-узла изменяется. В этом случае, параметр версии в URL-адресе файла контента, принимаемого посредством клиента, отличается от параметра версии локально кэшированного файла контента, и клиент должен снова загружать файл контента после того, как веб-узел модернизируется, из веб-узла. Согласно вышеприведенной процедуре, разрешается проблема при обновлении кэша файла контента на стороне клиента после того, как модернизируется веб-узел.

[0033] В возможном проектном решении, файл cookie ответа по доступу переносит параметр версии, и текущий URL-адрес включает в себя URL-адрес первого JS-файла. Соответственно, способ дополнительно включает в себя: получение, посредством клиента, параметра версии из файла cookie, выполнение первого JS-файла и создание XmlHttpRequest-объекта, причем целевой URL-адрес в XmlHttpRequest-объекте включает в себя информацию исходного адреса второго JS-файла и параметр версии, XmlHttpRequest-объект используется для получения второго JS-файла из веб-сервера, и второй JS-файл указывается ссылкой посредством первого JS-файла. Согласно вышеприведенному способу, когда используется AJAX-технология, если первый JS-файл, включенный в индексный файл, возвращаемый посредством стороны системы веб-узла, ссылается на второй JS-файл, клиент должен создавать XmlHttpRequest-объект и снова получать второй JS-файл из веб-сервера.

[0034] Согласно другому аспекту, вариант осуществления настоящего изобретения предоставляет веб-сервер, причем веб-сервер, в частности, реализует функции веб-сервера в вышеприведенных способах. Функции могут реализовываться посредством использования аппаратных средств или могут реализовываться посредством использования аппаратных средств, выполняющих соответствующее программное обеспечение. Аппаратные средства или программное обеспечение включают в себя один или более модулей, соответствующих вышеприведенным функциям.

[0035] Согласно другому аспекту, вариант осуществления настоящего изобретения предоставляет прокси-сервер, причем прокси-сервер, в частности, реализует функции прокси-сервера в вышеприведенных способах. Функции могут реализовываться посредством использования аппаратных средств или могут реализовываться посредством использования аппаратных средств, выполняющих соответствующее программное обеспечение. Аппаратные средства или программное обеспечение включают в себя один или более модулей, соответствующих вышеприведенным функциям.

[0036] Согласно еще одному другому аспекту, вариант осуществления настоящего изобретения предоставляет клиент, причем клиент, в частности, реализует функции клиента в вышеприведенных способах. Функции могут реализовываться посредством использования аппаратных средств или могут реализовываться посредством использования аппаратных средств, выполняющих соответствующее программное обеспечение. Аппаратные средства или программное обеспечение включают в себя один или более модулей, соответствующих вышеприведенным функциям.

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

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

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

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

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

Краткое описание чертежей

[0042] Чтобы более понятно описывать технические решения в вариантах осуществления настоящего изобретения или в предшествующем уровне техники, далее кратко описываются прилагаемые чертежи, требуемые для описания вариантов осуществления или предшествующего уровня техники. Ясно, что прилагаемые чертежи в нижеприведенном описании показывают только некоторые варианты осуществления настоящего изобретения, и специалисты в данной области техники могут извлекать другие способы реализации настоящего изобретения из этих прилагаемых чертежей без творческих усилий. Все эти варианты осуществления или способы реализации должны попадать в пределы объема охраны настоящего изобретения.

[0043] Фиг. 1A является возможной принципиальной структурной схемой системы для реализации настоящего изобретения;

[0044] Фиг. 1B является другой возможной принципиальной структурной схемой системы для реализации настоящего изобретения;

[0045] Фиг. 1C является еще одной другой возможной принципиальной структурной схемой системы для реализации настоящего изобретения;

[0046] Фиг. 2 является принципиальной схемой компьютерного устройства согласно варианту осуществления настоящего изобретения;

[0047] Фиг. 3 является блок-схемой последовательности операций способа для осуществления доступа к веб-серверу посредством клиента-браузера согласно варианту осуществления настоящего изобретения;

[0048] Фиг. 4 является принципиальной структурной схемой веб-сервера согласно варианту осуществления настоящего изобретения;

[0049] Фиг. 5 является принципиальной структурной схемой прокси-сервера согласно варианту осуществления настоящего изобретения;

[0050] Фиг. 6 является принципиальной структурной схемой клиента-браузера согласно варианту осуществления настоящего изобретения; и

[0051] Фиг. 7 является принципиальной структурной схемой системы веб-узла согласно варианту осуществления настоящего изобретения.

Подробное описание вариантов осуществления

[0052] Ниже ясно и полностью описываются технические решения согласно вариантам осуществления настоящего изобретения со ссылкой на прилагаемые чертежи. Ясно, что описанные варианты осуществления представляют собой только некоторые, но не все варианты осуществления настоящего изобретения. Все остальные варианты осуществления, полученные специалистами в данной области техники на основе вариантов осуществления настоящего изобретения без творческих усилий, должны попадать в пределы объема охраны настоящего изобретения.

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

[0054] В вариантах осуществления настоящего изобретения, веб-сервер выполнен с возможностью развертывать веб-приложение и сохранять файл ресурсов. Несколько веб-серверов могут составлять веб-серверный кластер, чтобы переносить веб-узел. Файлы, хранимые на веб-сервере, в общем, упоминаются в качестве файлов ресурсов, включающих в себя конкретный для приложения конфигурационный файл, шаблон веб-страниц и т.п. Код приложения может осуществлять доступ к этим файлам посредством использования файловой системы. Файл контента, упомянутый в вариантах осуществления настоящего изобретения, в общем, представляет собой статический файл ресурсов, размещающийся на веб-сервере. Статический файл ресурсов является согласованным для всех пользователей и, в общем, не изменяется при нормальных обстоятельствах, когда запущено приложение. Файл контента может включать в себя мультимедийный файл веб-узла (к примеру, изображение), файл каскадных таблиц стилей (Cascading Style Sheet, CSS) для описания того, как создавать веб-страницу на экране, JavaScript-код, который может загружаться и выполняться посредством браузера, HTML-страницу, которая не включает в себя динамический контент, и т.п. При приеме HTTP-запроса, веб-сервер возвращает, в клиент, HTML, соответствующий HTTP-запросу, и адрес файла контента, на который ссылается HTML.

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

[0056] Основные элементы, предусмотренные в вариантах осуществления настоящего изобретения, являются следующими.

[0057] Клиент: Веб-браузер запущен на клиенте, и ввиду этого клиент также упоминается как клиент-браузер. Клиент-браузер соединяется с прокси-сервером и веб-сервером, которые находятся на стороне системы, посредством использования сети, и клиент-браузер выполнен с возможностью инициировать HTTP-запрос. Клиент, предусмотренный в этой заявке, может включать в себя различные карманные устройства, устройства в транспортных средствах, носимые устройства, вычислительные устройства или другие устройства обработки, соединенные с различными типами сетей, причем устройства содержат функции радиосвязи, и клиент также может включать в себя различные формы клиентов, мобильные станции (Mobile station, сокращенно MS), терминалы (terminal), терминальное оборудование (Terminal Equipment) и т.п. Для простоты описания, все вышеупомянутые устройства называются "клиентами" в этой заявке.

[0058] Веб-сервер: Веб-сервер выполнен с возможностью развертывать веб-приложение и сохранять файл контента (т.е. статический файл ресурсов), и веб-сервер соединяется с сервером администрирования и прокси-сервером. Могут быть предусмотрены один или более веб-серверов, и несколько веб-серверов составляют веб-серверный кластер. При приеме запроса на доступ, отправленного посредством клиента-браузера, прокси-сервер может выполнять балансировку нагрузки, чтобы выбирать надлежащий веб-сервер из веб-серверного кластера для того, чтобы обслуживать клиент-браузер.

[0059] Прокси-модуль: Прокси-модуль может реализовывать, в форме подключенного модуля (plug-in), запрос параметра версии файла контента и обновления URL-адреса файла контента. Необязательно, прокси-модуль дополнительно может обновлять контент файла cookie в ответе по доступу, отправленном посредством веб-сервера. В примере, прокси-модуль может соединяться с модулем администрирования и получать параметр версии для текущей версии веб-узла из модуля администрирования.

[0060] Модуль администрирования: Модуль администрирования выполнен с возможностью предоставлять функцию администрирования версий веб-узла, функцию формирования параметров версии и т.п. Функция формирования параметров версии может реализовываться посредством средства формирования версий в модуле администрирования. Параметр версии используется для того, чтобы указывать текущую версию веб-узла, которая может представлять собой параметр в любом формате или в любой форме при условии, что версия веб-узла может идентифицироваться уникально. Номер версии веб-узла может непосредственно использоваться в качестве конкретного параметра версии, или случайный код формируется согласно номеру версии веб-узла и используется в качестве параметра версии для текущей версии веб-узла. Конкретная форма параметра версии не ограничена в вариантах осуществления настоящего изобретения. Модуль администрирования сохраняет номер версии для текущей версии веб-узла и возвращает, при приеме обращения на запрос файла, которое отправляется посредством прокси-модуля, параметр версии, соответствующий текущей версии веб-узла. Когда веб-узел модернизируется, модуль администрирования получает номер версии для текущей версии веб-узла различными способами. Модуль администрирования записывает идентификаторы веб-узлов, причем один идентификатор веб-узла соответствует одному веб-узлу и может использоваться для того, чтобы уникально идентифицировать веб-узел. Каждая версия веб-узла соответствует одной модернизации веб-узла, и каждая версия веб-узла соответствует уникальному параметру версии.

[0061] Вышеприведенный прокси-модуль и модуль администрирования могут реализовываться на веб-сервере в форме функциональных модулей или могут реализовываться на независимых физических серверах. При реализации в форме независимого физического сервера, прокси-модуль может упоминаться в качестве прокси-сервера. При реализации в форме независимого физического сервера, модуль администрирования может упоминаться в качестве сервера администрирования. Варианты осуществления настоящего изобретения акцентируют внимание на функциях прокси-модуля и модуля администрирования. Специалисты в данной области техники могут понимать, что функции прокси-модуля и модуля администрирования могут реализовываться на другом сервере, что не ограничивается в вариантах осуществления настоящего изобретения. В примере, прокси-сервер развертывается на внешнем интерфейсе веб-сервера и может использоваться в качестве модуля балансировки нагрузки для обработки HTTP-запросов для веб-сервера. Функция прокси-сервера может быть интегрирована в существующий Nginx или HAProxy.

[0062] Как показано на фиг. 1A, фиг. 1A является принципиальной структурной схемой системы веб-узла согласно варианту осуществления настоящего изобретения. Клиент соединяется с веб-сервером посредством использования сети, веб-браузер устанавливается на клиенте, прокси-сервер расположен между клиентом и веб-сервером, и сервер администрирования выполнен с возможностью администрировать информацию версии веб-узла. В этом случае, веб-сервер, прокси-сервер и сервер администрирования распределены по различным физическим серверам. Как показано на фиг. 1B, фиг. 1B является принципиальной структурной схемой другой системы веб-узла согласно варианту осуществления настоящего изобретения. В этом случае, прокси-сервер в форме прокси-модуля развертывается вместе с одним веб-сервером в веб-серверном кластере. Как показано на фиг. 1C, фиг. 1C является принципиальной структурной схемой еще одной другой системы веб-узла согласно варианту осуществления настоящего изобретения. Сервер администрирования в форме модуля администрирования развертывается вместе с прокси-сервером. Следует отметить, что варианты осуществления настоящего изобретения не ограничивают строго конкретный способ аппаратной реализации системы веб-узла при условии, что элементы в системе могут реализовывать соответствующие функции в вариантах осуществления настоящего изобретения.

[0063] Фиг. 2 является принципиальной схемой компьютерного устройства согласно варианту осуществления настоящего изобретения. Компьютерное устройство 200 включает в себя, по меньшей мере, один процессор 201, шину 202 связи, запоминающее устройство 203 и, по меньшей мере, один интерфейс 204 связи.

[0064] Процессор 201 может представлять собой центральный процессор (CPU) общего назначения, микропроцессор, специализированную интегральную схему (application-specific integrated circuit, ASIC) либо одну или более интегральных схем для управления выполнением программы, реализующей решение настоящего изобретения.

[0065] Шина 202 связи может включать в себя тракт для передачи информации между вышеприведенными компонентами. Интерфейс 304 связи использует любое устройство в форме приемо-передающего устройства для того, чтобы обмениваться данными с другим устройством или сетью связи, такой как Ethernet-сеть, сеть радиодоступа (RAN), беспроводная локальная вычислительная сеть (Wireless Local Area Network, WLAN).

[0066] Запоминающее устройство 203 может представлять собой постоянное запоминающее устройство (read-only memory, ROM) или другой тип устройства статического хранения данных для сохранения статической информации и инструкций, оперативное запоминающее устройство (random access memory, RAM) или другой тип устройства динамического хранения данных для сохранения информации и инструкций, электрически стираемое программируемое постоянное запоминающее устройство (Electrically Erasable Programmable Read-Only Memory, EEPROM), постоянное запоминающее устройство на компакт-дисках (Compact Disc Read-Only Memory, CD-ROM) или другое устройство хранения данных на оптических дисках (optical disk storage), устройство хранения данных на оптических дисках (optical disc storage) (включающее в себя компакт-диск, лазерный диск, оптический диск, универсальный цифровой диск, оптический Blu-ray-диск и т.п.), носитель хранения данных на магнитных дисках или другое магнитное устройство хранения данных либо любой другой машинодоступный носитель, который может использоваться для того, чтобы переносить или сохранять ожидаемый программный код в форме инструкций или структуры данных, но не ограничено этим. Запоминающее устройство может существовать независимо и соединяется с процессором посредством использования шины. Запоминающее устройство может быть интегрировано с процессором.

[0067] Запоминающее устройство 203 выполнено с возможностью сохранять код приложения решения настоящего изобретения, и процессор 201 управляет выполнением. Процессор 201 выполнен с возможностью осуществлять код приложения, сохраненный в запоминающем устройстве 203.

[0068] В конкретной реализации, в варианте осуществления, процессор 201 может включать в себя один или более CPU, например, CPU0 и CPU1 на фиг. 2.

[0069] В конкретной реализации, в варианте осуществления, компьютерное устройство 200 может включать в себя несколько процессоров, например, процессор 201 и процессор 208 на фиг. 2. Каждый из процессоров может представлять собой одноядерный процессор (с одним CPU) или может представлять собой многоядерный процессор (с несколькими CPU). Процессоры в данном документе могут представлять собой одно или более устройств, схем и/или ядер обработки для обработки данных (например, компьютерных программных инструкций).

[0070] В конкретной реализации, в варианте осуществления, компьютерное устройство 200 дополнительно может включать в себя устройство 205 вывода и устройство 206 ввода. Устройство 205 вывода обменивается данными с процессором 201 и может отображать информацию несколькими способами. Например, устройство 205 вывода может представлять собой жидкокристаллический дисплей (liquid crystal display, LCD), устройство отображения на светоизлучающих диодах (light emitting diode, LED), устройство отображения на электронно-лучевой трубке (cathode ray tube, CRT), проектор и т.п. Устройство 206 ввода обменивается данными с процессором 201 и может принимать пользовательский ввод несколькими способами. Например, устройство 206 ввода может представлять собой мышь, клавиатуру, устройство с сенсорным экраном, сенсорное устройство и т.п.

[0071] Вышеприведенное компьютерное устройство 200 может представлять собой компьютерное устройство общего назначения или специализированное компьютерное устройство. В конкретной реализации, компьютерное устройство 200 может представлять собой настольный компьютер, портативный компьютер, сетевой сервер, карманный компьютер (персональное цифровое устройство, PDA), мобильный телефон, планшетный компьютер, беспроводное терминальное устройство, устройство связи, встроенное устройство или устройство со структурой, аналогичной структуре на фиг. 2. Этот вариант осуществления настоящего изобретения не ограничивает тип компьютерного устройства 200.

[0072] Веб-сервер, прокси-сервер, сервер администрирования и клиент на фиг. 1A, фиг. 1B и фиг. 1C могут представлять собой устройство, показанное на фиг. 2. Запоминающее устройство сохраняет один или более программных модулей для реализации функций веб-сервера, сервера администрирования и клиента (например, функции администрирования версий веб-узла и функции формирования параметров версии на сервере администрирования). Веб-сервер, прокси-сервер, сервер администрирования и клиент могут реализовывать, посредством использования процессора и программного кода, сохраненного в запоминающем устройстве, способ для осуществления доступа к веб-серверу посредством клиента-браузера.

[0073] Следует отметить, что компьютерное устройство, показанное на фиг. 2, предоставляет только возможный способ аппаратной реализации элементов в системе веб-узла. Аппаратные компоненты компьютерного устройства могут добавляться или удаляться согласно различиям или изменениям функций элементов в системе, так что они совпадают с функциями элементов в системе.

[0074] В вышеприведенной системе веб-узла, веб-сервер сохраняет статический файл ресурсов веб-узла. Прокси-сервер перехватывает ответ по доступу, который возвращается в клиент-браузер посредством веб-сервера, и добавляет, в текущий URL-адрес статического файла ресурсов, включенного в страницу, к которой должен быть осуществлен доступ, параметр версии, соответствующий номеру текущей версии веб-узла. Прокси-сервер возвращает текущий URL-адрес в клиент-браузер. Посредством использования решения, предоставленного в этой заявке, клиент-браузер может получать статический файл ресурсов из веб-сервера согласно текущему URL-адресу. В ходе модернизации версии веб-узла, разработчик не должен обязательно изменять путь к статическому файлу ресурсов, не должен обязательно вручную обновлять URL-адрес файла ресурсов и также не должен обязательно обновлять имя статического файла ресурсов. Это повышает эффективность модернизации веб-узлов. С одной стороны, имя файла для статического файла ресурсов не должно обязательно изменяться в процессе модернизации веб-узла, и ввиду этого другой файл, ссылающийся на статический файл ресурсов, не затрагивается, и имя файла для другого файла, ссылающегося на статический файл ресурсов, также не должно обязательно изменяться, что исключает полную модернизацию крупных файлов веб-узла и снижает риски при модернизации. С другой стороны, в вышеприведенном процессе модернизации веб-узла, путь к статическому файлу ресурсов не должен обязательно изменяться, и ввиду этого путь к статическому файлу ресурсов не должен обязательно перезаписываться разработчиком, что уменьшает затраты на разработку.

[0075] Как показано на фиг. 3, фиг. 3 является блок-схемой последовательности операций способа для осуществления доступа к веб-серверу посредством клиента-браузера согласно варианту осуществления настоящего изобретения, включающего в себя:

[0076] Этап 301. Обновление статического файла ресурсов веб-узла.

[0077] Когда веб-узел модернизируется, обновленные статические файлы ресурсов развертываются на веб-сервере веб-узла, и определяется номер текущей версии веб-узла.

[0078] Этап 302. Сервер администрирования администрирует версию веб-узла и записывает номер текущей версии веб-узла.

[0079] Следует отметить, что в конкретной реализации решения, сервер администрирования может получать номер версии для текущей версии веб-узла любым из следующих способов:

[0080] Способ 1: Выполнение файла сценария модернизации. Сценарий модернизации запущен на веб-сервере или другом независимом сервере, и номер версии веб-узла конфигурируется в файле сценария модернизации. В процессе модернизации веб-узла, посредством запуска файла сценария модернизации, веб-узел на веб-сервере сначала модернизируется, чтобы обновлять статический файл ресурсов, и затем файл сценария модернизации вызывает интерфейс сервера администрирования, чтобы конфигурировать, на сервере администрирования, номер последней версии веб-узла.

[0081] Способ 2: Выполнение вручную. Специалисты по эксплуатации и обслуживанию модернизируют веб-узел посредством обновления статического файла ресурсов на веб-сервере веб-узла и записи числа новой версии веб-узла в окне администрирования посредством использования интерфейса, предоставленного посредством сервера администрирования.

[0082] Способ 3: Конфигурирование средства администрирования. Средство администрирования может использоваться для того, чтобы отслеживать процесс модернизации веб-узла, и автоматически получает номер модернизированной версии веб-узла из репозитория версий, или средство администрирования может непосредственно отслеживать изменение номера версии веб-узла на веб-сервере. В репозитории версий может быть предусмотрено множество версий для идентичного веб-узла. Средство администрирования может использовать несколько способов для того, чтобы получать последнюю версию, до которой модернизируется веб-узел, включающих в себя, но не только, предварительное задание правила определения номера версии, согласование начального времени модернизации и т.п.

[0083] Способ 4: Веб-сервер сохраняет файл описания версии для описания текущей версии веб-узла. Сервер администрирования может получать файл описания версии, чтобы извлекать номер версии веб-узла.

[0084] Этап 303. Сервер администрирования формирует параметр версии, соответствующий номеру версии для текущей версии веб-узла, и записывает соответствие между идентификатором, номером версии и параметром версии веб-узла, причем идентификатор веб-узла представляет собой уникальный идентификатор веб-узла на сервере администрирования.

[0085] Следует отметить, что номер версии для текущей версии веб-узла может непосредственно использоваться в качестве параметра версии. Конкретная форма реализации параметра версии не ограничена в этом варианте осуществления настоящего изобретения.

[0086] Этап 304. Клиент-браузер отправляет запрос на доступ на веб-сервер, причем запрос на доступ отправляется на веб-сервер посредством использования прокси-сервера.

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

[0088] В примере, веб-узел может развертываться на одном веб-сервере или развернутый в веб-серверном кластере, состоящем из нескольких серверов. Прокси-сервер может использоваться для того, чтобы выполнять балансировку нагрузки для HTTP-запросов, с тем чтобы выбирать надлежащий веб-сервер для HTTP-запросов.

[0089] Этап 305. Веб-сервер возвращает первый ответ по доступу в клиент-браузер посредством использования прокси-сервера, причем первый ответ по доступу переносит индексный файл, и индексный файл включает в себя начальный URL-адрес статического файла ресурсов, включенного в страницу, к которой должен быть осуществлен доступ.

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

[0091] Этап 306. Прокси-сервер перехватывает первый ответ по доступу и отправляет обращение на запрос версии на сервер администрирования, причем обращение на запрос версии переносит идентификатор веб-узла для выполнения запроса относительно параметра версии, соответствующего номеру версии для текущей версии веб-узла.

[0092] В примере, прокси-сервер не перехватывает все файлы, возвращаемые посредством веб-сервера в клиент-браузер. Прокси-сервер определяет, согласно типу файла для файла, возвращаемого посредством веб-сервера, то, следует или нет выполнять перехват, и перехватывается только файл, который переносит URL-адрес статического файла ресурсов. В частности, прокси-сервер определяет тип файла для индексного файла, переносимого в первом ответе по доступу. Когда файл представляет собой CSS-файл или HTML-файл, первый ответ по доступу перехватывается. Когда файл не представляет собой CSS-файл или HTML-файл, первый ответ по доступу прозрачно передается в клиент-браузер.

[0093] В другом примере, прокси-сервер реализует функцию сервера версий. В этом случае, прокси-сервер формирует параметр версии для текущей версии веб-узла или непосредственно использует номер версии для текущей версии веб-узла в качестве параметра версии.

[0094] Этап 307. Сервер администрирования выполняет запрос, согласно идентификатору веб-узла, переносимому в обращении на запрос версии, соответствие между идентификатором веб-узла и номером версии и параметр версии веб-узла, чтобы получать параметр версии, соответствующий номеру текущей версии веб-узла, и возвращает ответ на запрос параметра версии в прокси-сервер, причем ответ на запрос параметра версии переносит параметр версии.

[0095] Этап 308. Прокси-сервер принимает ответ на запрос параметра версии и формирует текущий URL-адрес статического файла ресурсов согласно исходному URL-адресу статического файла ресурсов и параметру версии для текущей версии веб-узла, причем текущий URL-адрес включает в себя часть информации пути и часть для поиска, часть информации пути включает в себя информацию исходного пути файла контента, и часть для поиска включает в себя параметр версии для текущей версии веб-узла.

[0096] Прокси-сервер заменяет начальный URL-адрес статического файла ресурсов, включенного в индексный файл, на сформированный текущий URL-адрес.

[0097] В качестве примера, структура URL-адреса описывается в этом варианте осуществления настоящего изобретения. Согласно определению (гиперссылка: https://www.ietf.org/rfc/rfc1738.txt) в стандарте RFC 1738, формат URL-адреса является следующим:

http://<host>:<port>/<path>?<searchpart>,

где <host> представляет доменное имя, или IP-адрес, <port> является номером порта, <path> является частью информации пути, которая может использоваться для указания пути для получения статического файла ресурсов, и <searchpart> является частью для поиска, представляющей параметр URL. "?" представляет начальную точку части для поиска, отделяющую часть для поиска от части информации пути. В этом варианте осуществления настоящего изобретения, параметр версии переносится в части для поиска в вышеприведенном URL-формате, и ввиду этого путь для получения статического файла ресурсов не затрагивается. Когда веб-узел модернизируется, часть информации пути не изменяется, и ввиду этого разработчик не должен обязательно обновлять пути к статическим файлам ресурсов и также не должен обязательно изменять имена файлов статических файлов ресурсов. Это уменьшает затраты на разработку.

[0098] В качестве примера, в конкретном способе реализации, исходный URL индексного файла представляет собой <link src="theme/logo.gif">, и прокси-сервер заменяет исходный URL-адрес на <link src="theme/logo.gif?ttl=345672">, где строка 345672 представляет собой параметр версии, соответствующий текущей версии веб-узла, на котором расположен статический файл ресурсов logo.gif, и строка может формироваться посредством выполнения хэша для номера версии.

[0099] Этап 309. Прокси-сервер возвращает второй ответ по доступу в клиент-браузер, причем второй ответ по доступу переносит обновленный индексный файл, и обновленный индексный файл включает в себя текущий URL-адрес статического файла ресурсов.

[0100] Этап 310. Клиент-браузер принимает второй ответ по доступу и извлекает обновленный URL-адрес статического файла ресурсов.

[00101] Этап 311. Клиент-браузер отправляет запрос на получение файла на веб-сервер, причем запрос на получение файла переносит обновленный URL-адрес статического файла ресурсов, чтобы запрашивать статический файл ресурсов из веб-сервера. Веб-сервер принимает запрос на получение файла, извлекает статический файл ресурсов согласно текущему URL-адресу статического файла ресурсов и возвращает статический файл ресурсов в клиент-браузер.

[00102] В примере, клиент-браузер дополнительно может кэшировать принимаемый статический файл ресурсов локально, записывая имя файла и параметр версии статического файла ресурсов. Дополнительно, при осуществлении доступа к веб-узлу снова, после получения URL-адреса статического файла ресурсов, включенного в страницу, к которой должен быть осуществлен доступ, клиент-браузер дополнительно может определять, согласно имени файла и параметру версии, включенному в URL-адрес статического файла ресурсов, то, кэширован локально или нет статический файл ресурсов, который должен быть считан. Если кэширован, статический файл ресурсов, который должен быть считан, не должен обязательно снова получаться из веб-сервера. Это повышает скорость доступа к веб-узлу.

[00103] Дополнительно, посредством использования механизма, в котором HTTP-протокол поддерживает кэширование, первый ответ по доступу дополнительно включает в себя параметр настройки кэша, который используется для того, чтобы указывать то, должна или нет сторона клиента-браузера кэшировать статический файл ресурсов, и длительность кэширования. В частности, параметр настройки кэша может представлять собой кэш параметров и/или истечение, и настройка кэша основана на определении в HTTP-протоколе. Второй ответ по доступу, который отправляется в клиент-браузер посредством прокси-сервера, также переносит параметр настройки кэша. Параметр настройки кэша переносит рекомендуемое значение времени истечения кэша. Если клиент-браузер выбирает разрешать это рекомендуемое значение, статический файл ресурсов кэшируется в течение длительности, которая соответствует рекомендуемому значению. В пределах этой длительности, локальная копия статического файла ресурсов непосредственно используется, и статический файл ресурсов не должен обязательно снова получаться из веб-сервера. Это уменьшает потребление полосы пропускания сети. После того, как веб-узел модернизируется, параметр версии, соответствующий статическому файлу ресурсов, изменяется. Клиент-браузер может определять, согласно имени файла и параметру версии статического файла ресурсов, которые включены в принимаемый URL-адрес, то что локально сохраненный статический файл ресурсов истек. В этом случае, вышеприведенная процедура для получения статического файла ресурсов должна выполняться для того, чтобы обновлять локально кэшированный статический файл ресурсов.

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

[00105] Следует отметить, что, в этом варианте осуществления настоящего изобретения, предпочтительно, домашняя страница (home.html) веб-узла не кэшируется. Когда клиент-браузер должен входить в учетную запись на домашней странице веб-узла, индексный файл, соответствующий домашней странице, всегда должен получаться из веб-сервера. Когда версия веб-узла обновляется, клиент-браузер может получать актуальный статический файл ресурсов.

[00106] Прокси-сервер также упоминается как модуль балансировки нагрузки уровня 7. Например, существующий Nginx и существующий HAProxy могут предоставлять такие услуги.

[00107] Дополнительно, в примере, клиент-браузер может поддерживать AJAX (асинхронный JavaScript-язык и расширяемый язык разметки, асинхронный JavaScript-язык и расширяемый язык разметки). На обычной веб-странице (без использования AJAX-технологии), если контент страницы должен обновляться, должна перезагружаться вся веб-страница, даже если изменяется только часть контента веб-страницы. Тем не менее, для AJAX-технологии, асинхронная передача данных используется между клиентом-браузером и веб-сервером, и обновление может выполняться для части контента веб-страницы без перезагрузки всей веб-страницы. Таким образом, объем данных, загружаемых из сервера, может уменьшаться для веб-страницы.

[00108] AJAX представляет собой технологию веб-разработки для создания приложений с интерактивными веб-страницами. Сторона клиента-браузера включает в себя AJAX-механизм, причем AJAX-механизм может получать статический файл ресурсов из веб-сервера посредством использования XmlHttpRequest-объекта.

[00109] В примере, AJAX-механизм запускает файл JavaScript (JS), чтобы создавать XmlHttpRequest-объект. XmlHttpRequest-объект включает в себя HTTP-метод (Get/Post), целевой URL-адрес и функцию обратного вызова, причем целевой URL-адрес представляет собой URL-адрес статического файла ресурсов, который должен быть получен. Следует отметить, что в этой заявке, способ для создания XmlHttpRequest-объекта посредством AJAX-механизма посредством использования JavaScript может быть общепринятым способом в существующей AJAX-технологии, что не ограничивается в этой заявке.

[00110] Дополнительно, этап 309 дополнительно может включать в себя: прокси-сервер добавляет, в файл cookie второго ответа по доступу, параметр версии, соответствующий текущей версии веб-узла, причем обновленный индексный файл, переносимый во втором ответе по доступу, включает в себя имя файла для первого JS-файла. Этап 310 дополнительно может включать в себя: AJAX-механизм выполняет первый JS-файл, чтобы создавать XmlHttpRequest-объект, причем целевой URL-адрес в XmlHttpRequest-объекте включает в себя имя файла для второго JS-файла и параметр версии, XmlHttpRequest-объект используется для получения второго JS-файла из веб-сервера, и второй JS-файл указывается ссылкой посредством первого JS-файла.

[00111] Согласно вышеприведенному способу, когда клиент-браузер поддерживает AJAX-технологию, и первый JS-файл, включенный в индексный файл, который возвращается посредством веб-сервера, должен ссылаться на второй JS-файл, AJAX-механизм клиента-браузера создает XmlHttpRequest-объект и добавляет параметр версии в целевой URL-адрес второго JS-файла, переносимого в XmlHttpRequest-объекте, так что второй JS-файл, полученный после того, как веб-узел модернизируется, может получаться из веб-сервера. Это разрешает проблему при получении и обновлении кэша статического файла ресурсов в случае AJAX-запроса.

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

[00113] Согласно вышеприведенным вариантам осуществления способа, как показано на фиг. 4, фиг. 4 является принципиальной структурной схемой веб-сервера согласно варианту осуществления настоящего изобретения. Веб-сервер 400 включает в себя: приемный модуль 401 сервера, модуль 402 получения сервера, модуль 403 формирования сервера и модуль 404 отправки сервера.

[00114] Приемный модуль 401 сервера выполнен с возможностью принимать запрос на доступ из клиента, причем запрос на доступ указывает страницу, к которой должен быть осуществлен доступ на веб-узле.

[00115] Модуль 402 получения сервера выполнен с возможностью получать начальный универсальный указатель ресурса (URL-адрес) файла контента, включенного в страницу, к которой должен быть осуществлен доступ, и параметр версии для текущей версии веб-узла, причем начальный URL-адрес включает в себя информацию исходного пути файла контента, каждая версия веб-узла соответствует одной модернизации веб-узла, и каждая версия веб-узла соответствует уникальному параметру версии.

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

[00117] Модуль 404 отправки сервера выполнен с возможностью возвращать ответ по доступу в клиент, причем ответ по доступу переносит текущий URL-адрес файла контента.

[00118] Дополнительно, модуль 402 получения сервера может получать параметр версии для текущей версии веб-узла несколькими способами, которые могут конкретно представлять собой следующее:

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

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

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

[00119] Модуль 402 получения сервера, в частности, выполнен с возможностью получать номер версии для текущей версии веб-узла любым из следующих способов:

- способ 1: получение файла описания версии веб-узла и считывание номера версии для текущей версии веб-узла из файла описания версии;

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

- способ 3: выполнение файла сценария модернизации, и после завершения модернизации веб-узла, конфигурирование номера версии для текущей версии веб-узла; или

- способ 4: отслеживание процесса модернизации версии веб-узла, и после того, как определяется завершение модернизации версии веб-узла, считывание номера версии для текущей версии веб-узла из репозитория версий.

[00120] Модуль 402 получения сервера, в частности, выполнен с возможностью считывать начальный URL-адрес файла контента, включенного в индексный файл, соответствующий странице, к которой должен быть осуществлен доступ; и

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

[00121] Дополнительно, ответ по доступу, возвращаемый посредством веб-сервера в клиент, включает в себя параметр настройки кэша, который используется для того, чтобы указывать то, должен или нет клиент кэшировать файл контента, и длительность кэширования. Файл cookie ответа по доступу дополнительно может переносить параметр версии для текущей версии веб-узла, так что клиент может считывать параметр версии из файла cookie и добавлять параметр версии, когда адрес запроса файла контента формируется на стороне клиента.

[00122] Веб-сервер дополнительно может включать в себя модуль определения, выполненный с возможностью определять тип файла для индексного файла, соответствующего странице, к которой должен быть осуществлен доступ, и определять, согласно типу файла для индексного файла, то, включает или нет индексный файл в себя начальный URL-адрес файла контента. В частности, когда файл представляет собой CSS-файл или HTML-файл, индексный файл включает в себя начальный URL-адрес файла контента.

[00123] Как показано на фиг. 5, фиг. 5 является принципиальной структурной схемой прокси-сервера согласно варианту осуществления настоящего изобретения. Прокси-сервер 500 включает в себя: модуль 501 перехвата, модуль 502 получения прокси, модуль 503 формирования прокси и модуль 504 отправки прокси.

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

[00125] Модуль 502 получения прокси выполнен с возможностью получать параметр версии для текущей версии веб-узла, причем каждая версия веб-узла соответствует одной модернизации веб-узла, и каждая версия веб-узла соответствует уникальному параметру версии.

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

[00127] Модуль 504 отправки прокси выполнен с возможностью возвращать второй ответ по доступу в клиент, причем второй ответ по доступу переносит текущий URL-адрес файла контента.

[00128] Дополнительно, модуль 502 получения прокси может получать параметр версии для текущей версии веб-узла несколькими способами, которые могут конкретно представлять собой следующее:

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

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

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

[00129] Модуль 502 получения прокси, в частности, выполнен с возможностью получать номер версии для текущей версии веб-узла любым из следующих способов:

- способ 1: получение файла описания версии веб-узла и считывание номера версии для текущей версии веб-узла из файла описания версии;

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

- способ 3: выполнение файла сценария модернизации, и после завершения модернизации веб-узла, конфигурирование номера версии для текущей версии веб-узла; или

- способ 4: отслеживание процесса модернизации версии веб-узла, и после того, как определяется завершение модернизации версии веб-узла, считывание номера версии для текущей версии веб-узла из репозитория версий.

[00130] Начальный URL-адрес файла контента включен в индексный файл первого ответа по доступу; и

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

[00131] Как показано на фиг. 6, фиг. 6 является принципиальной структурной схемой клиента 600 согласно варианту осуществления настоящего изобретения, включающего в себя модуль 601 отправки клиента и приемный модуль 602 клиента.

[00132] Модуль 601 отправки клиента выполнен с возможностью отправлять запрос на доступ на веб-сервер, причем запрос на доступ указывает страницу, к которой должен быть осуществлен доступ на веб-узле.

[00133] Приемный модуль 602 клиента выполнен с возможностью принимать возвращаемый ответ по доступу, причем ответ по доступу переносит текущий URL-адрес файла контента, включенного в страницу, к которой должен быть осуществлен доступ, текущий URL-адрес включает в себя часть информации пути и часть для поиска, часть информации пути включает в себя информацию исходного пути файла контента, и часть для поиска включает в себя параметр версии для текущей версии веб-узла.

[00134] Модуль 601 отправки клиента дополнительно выполнен с возможностью отправлять сообщение с запросом файла на веб-сервер, с тем чтобы получать файл контента, причем сообщение с запросом файла переносит текущий URL-адрес файла контента.

[00135] Дополнительно, клиент может кэшировать принимаемый файл контента, и, в частности, клиент дополнительно включает в себя:

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

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

[00136] Дополнительно, файл cookie ответа по доступу переносит параметр версии, и текущий URL-адрес конкретно представляет собой URL-адрес первого JS-файла.

[00137] Клиент дополнительно включает в себя AJAX-механизм 605, выполненный с возможностью: получать параметр версии из файла cookie, выполнять первый JS-файл и создавать XmlHttpRequest-объект, причем целевой URL-адрес в XmlHttpRequest-объекте включает в себя информацию исходного адреса второго JS-файла и параметр версии, XmlHttpRequest-объект используется для получения второго JS-файла из веб-сервера, и второй JS-файл указывается ссылкой посредством первого JS-файла.

[00138] Как показано на фиг. 7, фиг. 7 представляет собой систему веб-узла согласно варианту осуществления настоящего изобретения, включающую в себя веб-сервер 400 и прокси-сервер 500.

[00139] Веб-сервер 400 выполнен с возможностью: принимать запрос на доступ из клиента, причем запрос на доступ указывает страницу, к которой должен быть осуществлен доступ на веб-узле, и возвращать первый ответ по доступу в клиент, причем первый ответ по доступу переносит начальный URL-адрес файла контента, включенного в страницу, к которой должен быть осуществлен доступ, и начальный URL-адрес включает в себя информацию исходного пути файла контента.

[00140] Прокси-сервер 500 выполнен с возможностью: перехватывать первый ответ по доступу и получать параметр версии для текущей версии веб-узла, причем каждая версия веб-узла соответствует одной модернизации веб-узла, и каждая версия веб-узла соответствует уникальному параметру версии.

[00141] Прокси-сервер 500 дополнительно выполнен с возможностью: формировать текущий URL-адрес файла контента согласно начальному URL-адресу файла контента и параметру версии для текущей версии веб-узла и возвращать второй ответ по доступу в клиент, причем второй ответ по доступу переносит текущий URL-адрес файла контента, текущий URL-адрес включает в себя часть информации пути и часть для поиска, часть информации пути включает в себя информацию исходного пути файла контента, и часть для поиска включает в себя параметр версии для текущей версии веб-узла.

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

[00143] В вариантах осуществления, соответствующих фиг. 4-7, веб-сервер 400, прокси-сервер 500, клиент-браузер 600 и сервер администрирования представляются в форме функциональных блоков/функциональных модулей. "Блок/модуль" в данном документе может означать специализированную интегральную схему (application-specific integrated circuit, ASIC), процессор и запоминающее устройство для выполнения одного или более программно- или микропрограммно-реализованных программ, интегральную логическую схему и/или другой компонент, который может предоставлять вышеприведенные функции. В простом варианте осуществления, специалисты в данной области техники могут выяснять то, что веб-сервер 400, прокси-сервер 500, клиент-браузер 600 и сервер администрирования могут иметь форму, показанную на фиг. 2. Например, приемный модуль 401 сервера, модуль 402 получения сервера, модуль 403 формирования сервера и модуль 404 отправки сервера могут реализовываться посредством использования процессора и запоминающего устройства на фиг. 2, которые, в частности, реализованы посредством использования процессора для того, чтобы выполнять программный код, сохраненный в запоминающем устройстве.

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

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

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

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

[00148] Специалисты в данной области техники должны понимать, что варианты осуществления настоящего изобретения могут предоставляться в качестве способа, устройства или компьютерного программного продукта. Следовательно, настоящее изобретение может использовать форму вариантов осуществления только в форме аппаратных средств, вариантов осуществления только в форме программного обеспечения или вариантов осуществления с комбинацией программного обеспечения и аппаратных средств. Кроме того, настоящее изобретение может использовать форму компьютерного программного продукта, который реализуется в одном или более машиноприменимых носителей хранения данных (в том числе, но не только, в запоминающем устройстве на дисках, CD-ROM, оптическом запоминающем устройстве и т.п.), которые включают в себя машиноприменимый программный код. Компьютерная программа сохраняется/распространяется на надлежащем носителе и предоставляется вместе или в качестве части других аппаратных средств либо также может распространяться в других формах, например, через Интернет или другие системы проводной или беспроводной связи.

[00149] Настоящее изобретение описывается в отношении блок-схем последовательности операций и/или блок-схем способа, устройства и компьютерного программного продукта согласно вариантам осуществления настоящего изобретения. Следует понимать, что компьютерные программные инструкции могут использоваться для того, чтобы реализовывать каждый процесс и/или каждый блок на блок-схемах последовательности операций способа и/или блок-схемах, а также комбинацию процесса и/или блока на блок-схемах последовательности операций способа и/или блок-схемах. Эти компьютерные программные инструкции могут предоставляться для компьютера общего назначения, специализированного компьютера, встроенного процессора или процессора любого другого программируемого устройства обработки данных таким образом, чтобы формировать машину, так что инструкции, выполняемые посредством компьютера или процессора любого другого программируемого устройства обработки данных, формируют устройство для реализации конкретной функции в одном или более процессов на блок-схемах последовательности операций способа и/или в одном или более блоков на блок-схемах.

[00150] Эти компьютерные программные инструкции также могут сохраняться в компьютерно-читаемом запоминающем устройстве, которое может инструктировать компьютеру или любому другому программируемому устройству обработки данных работать конкретным способом, так что инструкции, сохраненные в компьютерно-читаемом запоминающем устройстве, формируют изделие, которое включает в себя инструктирующее устройство. Инструктирующее устройство реализует конкретную функцию в одном или более процессов на блок-схемах последовательности операций способа и/или в одном или более блоков на блок-схемах.

[00151] Эти компьютерные программные инструкции также могут загружаться в компьютер или другое программируемое устройство обработки данных, так что последовательности операций и этапов выполняются на компьютере или другом программируемом устройстве, за счет этого формируя выполняемую компьютером обработку. Следовательно, инструкции, выполняемые для компьютера или другого программируемого устройства, предоставляют этапы для реализации конкретной функции в одном или более процессов на блок-схемах последовательности операций способа и/или в одном или более блоков на блок-схемах.

[00152] Хотя настоящее изобретение описано со ссылкой на его характерные признаки и варианты осуществления, ясно, что различные модификации и комбинации могут вноситься без отступления от сущности и объема настоящего изобретения. Соответственно, описание изобретения и прилагаемые чертежи представляют собой только примерное описание настоящего изобретения, заданного посредством прилагаемой формулы изобретения, и считаются охватывающими все без исключения модификации, изменения, комбинации или эквиваленты в пределах объема настоящего изобретения. Очевидно, что специалисты в данной области техники могут вносить различные модификации и изменения в настоящее изобретение без отступления от сущности и объема настоящего изобретения. Изобретение имеет намерение охватывать эти модификации и изменения при условии, что они попадают в область защиты, заданную посредством прилагаемой формулы изобретения или ее эквивалентных технологий.

Изобретение относится к средствам доступа к веб-узлам. Технический результат заключается в повышении эффективности модернизации веб-узлов. Принимают запрос на доступ из клиента, при этом запрос на доступ указывает страницу, к которой должен быть осуществлен доступ на веб-узле. Получают параметр версии для текущей версии веб-узла, при этом каждая версия веб-узла соответствует одной модернизации веб-узла и каждая версия веб-узла соответствует уникальному параметру версии. Формируют текущий URL-адрес файла контента согласно начальному URL-адресу файла контента и параметру версии для текущей версии веб-узла, при этом текущий URL-адрес содержит часть информации пути и часть для поиска, часть информации пути содержит информацию исходного пути файла контента и часть для поиска содержит параметр версии для текущей версии веб-узла. Возвращают ответ по доступу в клиент, при этом ответ по доступу переносит текущий URL-адрес файла контента, причем упомянутый текущий URL-адрес представляет собой URL-адрес первого файла JavaScript (JS), при этом упомянутый первый JS-файл используют для запуска получения второго JS-файла, а второй JS-файл указывается информацией исходного адреса второго JS-файла и параметром версии. 7 н. и 24 з.п. ф-лы, 9 ил.

1. Способ доступа к веб-узлам, содержащий этапы, на которых:

- принимают запрос на доступ из клиента, при этом запрос на доступ указывает страницу, к которой должен быть осуществлен доступ на веб-узле;

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

- получают параметр версии для текущей версии веб-узла, при этом каждая версия веб-узла соответствует одной модернизации веб-узла и каждая версия веб-узла соответствует уникальному параметру версии;

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

- возвращают ответ по доступу в клиент, при этом ответ по доступу переносит текущий URL-адрес файла контента, причем упомянутый текущий URL-адрес представляет собой URL-адрес первого файла JavaScript (JS), при этом упомянутый первый JS-файл используют для запуска получения второго JS-файла, а второй JS-файл указывается информацией исходного адреса второго JS-файла и параметром версии.

2. Способ по п. 1, в котором получение параметра версии для текущей версии веб-узла содержит любой из следующих способов, при которых:

- способ 1: получают номер версии для текущей версии веб-узла и формируют параметр версии согласно номеру версии;

- способ 2: получают номер версии для текущей версии веб-узла и используют номер версии для текущей версии веб-узла в качестве параметра версии или

- способ 3: отправляют обращение на запрос версии на сервер администрирования, при этом обращение на запрос версии переносит идентификатор веб-узла, и принимают параметр версии для текущей версии веб-узла, которая возвращается согласно идентификатору веб-узла посредством сервера администрирования.

3. Способ по п. 2, в котором получение номера версии для текущей версии веб-узла содержит любой из следующих способов, при которых:

- способ 1: получают файл описания версии веб-узла и считывают номер версии для текущей версии веб-узла из файла описания версии;

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

- способ 3: выполняют файл сценария модернизации и после завершения модернизации веб-узла конфигурируют номер версии для текущей версии веб-узла или

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

4. Способ по любому из пп. 1-3, в котором получение начального URL-адреса файла контента, содержащегося в странице, к которой должен быть осуществлен доступ, содержит этап, на котором считывают индексный файл, соответствующий странице, к которой должен быть осуществлен доступ, при этом индексный файл содержит начальный URL-адрес файла контента; и

- соответственно способ дополнительно содержит этап, на котором:

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

5. Способ по любому из пп. 1-3, в котором:

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

6. Способ по любому из пп. 1-3, в котором после приема запроса на доступ из клиента способ дополнительно содержит этап, на котором:

- определяют тип файла для индексного файла, соответствующего странице, к которой должен быть осуществлен доступ, и определяют, согласно типу файла для индексного файла, то, содержит ли индексный файл начальный URL-адрес файла контента.

7. Способ по любому из пп. 1-3, в котором:

- файл cookie ответа по доступу переносит параметр версии для текущей версии веб-узла.

8. Способ доступа к веб-узлам, содержащий этапы, на которых:

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

- получают параметр версии для текущей версии веб-узла, при этом каждая версия веб-узла соответствует одной модернизации веб-узла и каждая версия веб-узла соответствует уникальному параметру версии;

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

- возвращают второй ответ по доступу в клиент, при этом второй ответ по доступу переносит текущий URL-адрес файла контента, причем упомянутый текущий URL-адрес представляет собой URL-адрес первого файла JavaScript (JS), при этом упомянутый первый JS-файл используют для запуска получения второго JS-файла, а второй JS-файл указывается информацией исходного адреса второго JS-файла и параметром версии.

9. Способ по п. 8, в котором получение параметра версии для текущей версии веб-узла содержит любой из следующих способов, при которых:

- способ 1: получают номер версии для текущей версии веб-узла и формируют параметр версии согласно номеру версии;

- способ 2: получают номер версии для текущей версии веб-узла и используют номер версии для текущей версии веб-узла в качестве параметра версии; или

- способ 3: отправляют обращение на запрос версии на сервер администрирования, при этом обращение на запрос версии переносит идентификатор веб-узла, и принимают параметр версии для текущей версии веб-узла, которая возвращается согласно идентификатору веб-узла посредством сервера администрирования.

10. Способ по п. 9, в котором получение номера версии для текущей версии веб-узла содержит любой из следующих способов, при которых:

- способ 1: получают файл описания версии веб-узла и считывают номер версии для текущей версии веб-узла из файла описания версии;

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

- способ 3: выполняют файл сценария модернизации, и после завершения модернизации веб-узла конфигурируют номер версии для текущей версии веб-узла; или

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

11. Способ по любому из пп. 8-10, в котором:

- начальный URL-адрес файла контента содержится в индексном файле первого ответа по доступу; и

- соответственно способ дополнительно содержит этап, на котором:

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

12. Способ по любому из пп. 8-10, в котором:

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

13. Способ по любому из пп. 8-10, в котором после перехвата первого ответа по доступу из веб-сервера способ дополнительно содержит этап, на котором:

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

14. Способ по любому из пп. 8-10, в котором:

- файл cookie второго ответа по доступу переносит параметр версии для текущей версии веб-узла.

15. Способ доступа к веб-узлам, содержащий этапы, на которых:

- отправляют запрос на доступ на веб-сервер, при этом запрос на доступ указывает страницу, к которой должен быть осуществлен доступ на веб-узле;

- принимают возвращаемый ответ по доступу, при этом ответ по доступу переносит текущий URL-адрес файла контента, содержащегося в странице, к которой должен быть осуществлен доступ, текущий URL-адрес содержит часть информации пути и часть для поиска, часть информации пути содержит информацию исходного пути файла контента, и часть для поиска содержит параметр версии для текущей версии веб-узла, причем упомянутый текущий URL-адрес представляет собой URL-адрес первого файла JavaScript (JS); и

- отправляют сообщение с запросом файла на веб-сервер, с тем чтобы получать первый JS-файл, при этом сообщение с запросом файла переносит текущий URL-адрес первого JS-файла; и

выполняют упомянутый первый JS-файл для получения второго JS-файла от веб-сервера, используя информацию исходного адреса второго JS-файла и параметр версии.

16. Способ по п. 15, дополнительно содержащий этап, на котором:

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

17. Способ по п. 16, в котором перед отправкой сообщения с запросом файла на веб-сервер способ дополнительно содержит этап, на котором:

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

18. Способ по любому из пп. 15-17, в котором файл cookie ответа по доступу переносит параметр версии; и

- соответственно этап, на котором выполняют упомянутый первый JS-файл для получения второго JS-файла от веб-сервера, содержит этап, на котором:

- получают параметр версии из файла cookie, выполняют первый JS-файл и создают XmlHttpRequest-объект, при этом целевой URL-адрес в XmlHttpRequest-объекте содержит информацию исходного адреса второго JS-файла и параметр версии, XmlHttpRequest-объект используется для получения упомянутого второго JS-файла из веб-сервера, и второй JS-файл указывается ссылкой посредством первого JS-файла.

19. Веб-сервер, содержащий:

- приемный модуль сервера, выполненный с возможностью принимать запрос на доступ из клиента, при этом запрос на доступ указывает страницу, к которой должен быть осуществлен доступ на веб-узле;

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

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

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

20. Веб-сервер по п. 19, в котором модуль получения сервера, в частности, выполнен с возможностью получать параметр версии для текущей версии веб-узла любым из следующих способов:

- способ 1: получение номера версии для текущей версии веб-узла и формирование параметра версии согласно номеру версии;

- способ 2: получение номера версии для текущей версии веб-узла и использование номера версии для текущей версии веб-узла в качестве параметра версии; или

- способ 3: отправка обращения на запрос версии на сервер администрирования, при этом обращение на запрос версии переносит идентификатор веб-узла, и прием параметра версии для текущей версии веб-узла, которая возвращается согласно идентификатору веб-узла посредством сервера администрирования.

21. Веб-сервер по п. 20, в котором модуль получения сервера, в частности, выполнен с возможностью получать параметр версии для текущей версии веб-узла любым из следующих способов:

- способ 1: получение файла описания версии веб-узла и считывание номера версии для текущей версии веб-узла из файла описания версии;

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

- способ 3: выполнение файла сценария модернизации и после завершения модернизации веб-узла конфигурирование номера версии для текущей версии веб-узла; или

- способ 4: отслеживание процесса модернизации версии веб-узла и после того, как определяется завершение модернизации версии веб-узла, считывание номера версии для текущей версии веб-узла из репозитория версий.

22. Веб-сервер по любому из пп. 19-21, в котором:

- модуль получения сервера, в частности, выполнен с возможностью считывать начальный URL-адрес файла контента, содержащегося в индексном файле, соответствующем странице, к которой должен быть осуществлен доступ; и

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

23. Прокси-сервер, содержащий:

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

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

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

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

24. Прокси-сервер по п. 23, в котором модуль получения прокси, в частности, выполнен с возможностью получать параметр версии для текущей версии веб-узла любым из следующих способов:

- способ 1: получение номера версии для текущей версии веб-узла и формирование параметра версии согласно номеру версии;

- способ 2: получение номера версии для текущей версии веб-узла и использование номера версии для текущей версии веб-узла в качестве параметра версии; или

- способ 3: отправка обращения на запрос версии на сервер администрирования, при этом обращение на запрос версии переносит идентификатор веб-узла, и прием параметра версии для текущей версии веб-узла, которая возвращается согласно идентификатору веб-узла посредством сервера администрирования.

25. Прокси-сервер по п. 24, в котором модуль получения прокси, в частности, выполнен с возможностью получать параметр версии для текущей версии веб-узла любым из следующих способов:

- способ 1: получение файла описания версии веб-узла и считывание номера версии для текущей версии веб-узла из файла описания версии;

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

- способ 3: выполнение файла сценария модернизации и после завершения модернизации веб-узла конфигурирование номера версии для текущей версии веб-узла; или

- способ 4: отслеживание процесса модернизации версии веб-узла и после того, как определяется завершение модернизации версии веб-узла, считывание номера версии для текущей версии веб-узла из репозитория версий.

26. Прокси-сервер по любому из пп. 23-25, в котором:

- начальный URL-адрес файла контента содержится в индексном файле первого ответа по доступу; и

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

27. Клиент, содержащий:

- модуль отправки клиента, выполненный с возможностью отправлять запрос на доступ на веб-сервер, при этом запрос на доступ указывает страницу, к которой должен быть осуществлен доступ на веб-узле; и

- приемный модуль клиента, выполненный с возможностью принимать возвращаемый ответ по доступу, при этом ответ по доступу переносит текущий URL-адрес файла контента, содержащегося в странице, к которой должен быть осуществлен доступ, текущий URL-адрес содержит часть информации пути и часть для поиска, часть информации пути содержит информацию исходного пути файла контента, и часть для поиска содержит параметр версии для текущей версии веб-узла, причем упомянутый текущий URL-адрес представляет собой URL-адрес первого файла JavaScript (JS);

- модуль отправки клиента дополнительно выполнен с возможностью отправлять сообщение с запросом файла на веб-сервер, с тем чтобы получать первый JS-файл, при этом сообщение с запросом файла переносит текущий URL-адрес первого JS-файла; и

механизм, выполненный с возможностью: выполнять упомянутый первый JS-файл для получения второго JS-файла от веб-сервера, используя информацию исходного адреса второго JS-файла и параметр версии.

28. Клиент по п. 27, дополнительно содержащий:

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

29. Клиент по п. 28, дополнительно содержащий:

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

30. Клиент по любому из пп. 27-29, в котором файл cookie ответа по доступу переносит параметр версии;

- упомянутый механизм представляет собой AJAX-механизм и упомянутый AJAX-механизм выполнен с возможностью:

получать параметр версии из файла cookie, выполнять первый JS-файл и создавать XmlHttpRequest-объект, при этом целевой URL-адрес в XmlHttpRequest-объекте содержит информацию исходного адреса упомянутого второго JS-файла и параметр версии, XmlHttpRequest-объект используется для получения второго JS-файла из веб-сервера, и второй JS-файл указывается ссылкой посредством первого JS-файла.

31. Система веб-узла, содержащая веб-сервер и прокси-сервер, при этом:

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

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

- прокси-сервер дополнительно выполнен с возможностью: формировать текущий URL-адрес файла контента согласно начальному URL-адресу файла контента и параметру версии для текущей версии веб-узла и возвращать второй ответ по доступу в клиент, при этом второй ответ по доступу переносит текущий URL-адрес файла контента, текущий URL-адрес содержит часть информации пути и часть для поиска, часть информации пути содержит информацию исходного пути файла контента, и часть для поиска содержит параметр версии для текущей версии веб-узла, причем упомянутый текущий URL-адрес представляет собой URL-адрес первого файла JavaScript (JS), при этом упомянутый первый JS-файл используют для запуска получения второго JS-файла, а второй JS-файл указывается информацией исходного адреса второго JS-файла и параметром версии.