Файл: Разработка сайта по обмену книгами (Требования к приложению).pdf

Второй блок может отсутствовать, то есть HTTP-пакет может состоять только из блока заголовков. Так например при запросе главной страницы браузер Firefox отправил веб-серверу следующий HTTP-запрос:

GET/HTTP/1/1

Host:ya.ru

User-Agent:Mosilla/5.0(WindowsNT5.1;ru;rv:1.9.2)

Gecko/20100115Firefox/3.6

Accept:text/html,application/xhtml/xml;q=0.9*/*;q=0,8

Accept-Language:ru,en-us;q=0.7,en;q=0.3

Accept-Encoding:gzip.deflate

Accept-Charset:windows-1251.utf-8;q=0.7,*;q=0.7

Keep-Alive:115

Connection: keep-alive

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

Во-первых, самая первая строка:

GET/HTTP/1/1

"GET" — тип запроса. Два наиболее распространенных типа запросов — это GET и POST.

"/" указывает на то, что запрашивается главная страница сайта. В противном случае здесь указывается путь и имя запрашиваемой страницы или файла. "HTTP/1.1" — версия протокола HTTP.

Host:ya.ru

Параметр Host содержит домен сайта, к которому происходит обращение.

User-Agent:Mosilla/5.0(WindowsNT5.1;ru;rv:1.9.2)

Gecko/20100115Firefox/3.6

User-Agent содержит информацию о клиенте: тип браузера и операционная система

На данный HTTP-запрос веб-сервер отвечает следующим HTTP-ответом:

HTTP.1.1 200 ОК

Server:nginx

Date:Thu,25 Feb 2010 12:31:25GMT

Content-Tipe:text/html;charset=utf-8

Last-Modified:Tue,12 Jan 2010 15:29:06 GMT

Transfer-Encoding:chunked

Connection: keep-alive

Content- Encoding:gzip

<!DOCTYPE HTML PUBLIC”-//DTDHTML4.01 Transitional//EN”>

<title>Яндекс</title>

…

Пустая строка указывает на наличие блока данных (тела пакета).

В первой строке указывается версия протокола HTTP (HTTP/1.1) и код результата. Код результата 200 означает, что запрос выполнен успешно.

В описании протокола HTTP расписаны все коды результатов.

Server: nginx

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

Content-Tipe:text/html;charset=utf-8

Content-Type содержит тип переданных данных и их кодировку (charset). В блоке тела пакета содержится код запрошенной страницы.

1.3 Разработка web-приложения

Web-приложения (web applications, часто их называют Интернет-приложениями, internet applications) представляют собой набор страниц, объединенных общей функциональностью. Все Web- приложения

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

Как правило, веб-приложения не требуют установки дополнительного программного обеспечения на стороне клиента, а вся логика, в основном, выполняется на стороне сервера. Для отображения пользовательского интерфейса используется браузер – программа, способная распознавать язык разметки HTML (и сопутствующие технологии – таблицы стилей CSS, клиентский скриптовой язык программирования JavaScript и т.д.). Браузер обычно принято называть "тонким клиентом", т.е. клиентом, который содержит минимальное количество бизнес-логики.

1.3.1 Основные принципы построения web-приложения.

Началом «взрывного» роста Интернета принято считать начало 90х годов. Именно в это время появились и были стандартизованы протокол HTTP и язык описания страниц HTML, предназначенные для World Wide Web. Изначально WWW предназначался для публикации различной информации текстового и графического характера, поэтому язык HTML имел очень много недостатков, в первую очередь - практически отсутствовали механизмы управления размещением содержания на HTML-странице и взаимодействия с пользователями. Однако по мере роста интереса к Интернету росли и требования пользователей к содержанию (иначе - к контенту, от англ. content), что касалось как оформления опубликованной информации, так интерактивности при взаимодействии пользователя с сайтами. На сегодняшний день существующие в Интернете средства, реализованные в Web-серверах, средствах разработки сайтов и браузерах, позволяют говорить о создании так называемых Web-приложений, или приложений, построенных на мехнизмах Интернета и позволяющих пользователям взаимодействовать с Web-серверами. Безусловно, Web-приложения имеют клиент-серверную архитектуру, что диктуется общим построением Интернета. Как и традиционные программные приложения, Web-приложения имеют несколько аспектов: архитектура, подходы к разработке, безопасность приложений.

1.3.2 Область использования Web-приложения

Одной из важных характеристик Web-приложения является область использования приложения. По области использования Web-приложения делятся на intranet - внутрикорпоративные приложения, рассчитанные на использование во внутренней (локальной) сети, extranet - также внутрикорпоративные, но уже работающие во внешней среде (Интернете),

и, наконец, internet-приложения, рассчитанные на общее использование (например, Интернет-магазины). Такое деление возникает из-за различности подходов к построению таких приложений. Самые жесткие требования на разработку накладывает internet-приложение - это использование произвольных браузеров и максимальная безопасность в работе. При

разработке intranet- и extranet-приложений список используемого

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

1.3.3 Архитектура Web-приложения

Все Web-приложения можно условно разбить на три составные части: серверная часть, клиентское приложение и интерфейс:

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

- Клиентское приложение (браузер) последовательно запрашивает страницы с сервера, используя Dynamic HTML для управления интерфейсом и частичной обработки информации на компьютере клиента.

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

1.3.4 Основные требования, предъявляемые к web-приложению

Другая серьезная проблема в разработке Web-приложения -отслеживание сессии конкретного пользователя. Дело в том, что по определению HTTP-протокол не имеет понятия текущего состояния (stateless), т.е. очередной запрос страницы абсолютно не зависит от предыдущих запросов и потому не требует уникального идентификатора. Для отслеживания последовательных запросов и идентификации пользователя используются так называемые cookies. Cookies (русского термина не имеют, в единственном числе -cookie, точный перевод - «домашнее печенье») представляют собой небольшие файлы,

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

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

- наименование cookie;

- значение cookie, содержащее собственно информацию;

- домен. Указанный домен ограничивает область видимости cookie. По умолчанию домен устанавливается в домен текущей страницы (например, для www.lc.ni- домен Ic.ru);

- каталог. Указанный каталог ограничивает область видимости cookie внутри сервера. Каталог "/" используется для указания всех каталогов сервера. По умолчанию каталог устанавливается в каталог текущей страницы;

- срок действия. Срок ограничивает время действия cookie. По истечении указанного срока cookie удаляется с компьютера пользователя. По умолчанию срок действия не устанавливается, что означает удаление cookie при закрытии браузера (это эквивалентно установке срока действия в 0);

- секретность. Cookie с установленным свойством секретности могут посылаться на Web-сервер только по SSL-соединению. Это свойство используется редко. По умолчанию секретность не устанавливается.

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

Согласно стандарту браузер может как хранить и использовать cookies в своей работе, так и отключать их прием и сохранение в целях безопасности. Для этого в настройках браузеров обычно присутствует флажок, включающий и отключающий работу с cookie. По умолчанию работа с cookie включена, однако пользователь вправе отключить прием cookie. Для intranet- и extranet-приложений возможность отключения cookie можно игнорировать, просто введя некоторую дисциплину использования приложения. Для общих Web-приложений, опирающихся на использование cookies, такая возможность отключения представляет серьезную проблему, так как не существует точного способа определить, принимает ли браузер cookies.

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

1.3.5 Построение Web-приложения

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

Однако можно построить некоторую приблизительную схему приложения с авторизацией.

Все приложение делятся на три части -незащищенную, часть, обеспечивающую авторизацию пользователя, и защищенную.

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

Разберемся в том, как функционирует любое веб-приложение. Необходимые компоненты для работы пользователя с веб-приложением

– браузер (тонкий клиент),

- веб-сервер (серверная часть),

- протокол взаимодействия клиента и сервера (HTTP) и

- язык разметки для создания документов (HTML).

Для того, чтобы веб-приложение стало доступно, его необходимо разместить в рамках веб-сервера (специальная программа, которая обрабатывает запросы из сети). После этого приложение получит свой уникальный адрес в рамках протокола HTTP например,

http://www.myapplication.com/page1.html).

Используя этот адрес пользователь может обратиться к приложению. Для этого он должен запустить браузер (клиентское приложение) и ввести в адресной строке адрес приложения. В этот момент браузер сгенерирует запрос к серверу и отправит его, используя протокол HTTP.