ASP - Отправка содержимого в веб-обозреватель
По ходу обработки сценария на странице ASP текст и рисунки, не обрамленные ограничителями ASP или тегами <SCRIPT>, просто возвращаются в обозреватель. Кроме того, содержимое можно явным образом отправить в обозреватель с помощью объекта Response.
Отправка содержимого
Для отправки в обозреватель содержимого, обозначенного ограничителями ASP, или из процедуры, используется метод Write объекта Response. Например, в следующей инструкции показано, как отправлять пользователям разные приветствия в зависимости от того, посещали ли они данную страницу раньше:
<%
If blnFirstTime Then
Response.Write "<H3 ALIGN=CENTER>Welcome to the Overview Page.</H3>"
Else
Response.Write "<H3 ALIGN=CENTER>Welcome Back to the Overview Page.</H3>"
End If
%>
Для отправки содержимого обратно пользователю вне текста процедуры нет необходимости пользоваться методом Response.Write. Если содержимое не заключено между ограничителями сценария, оно непосредственно отправляется в обозреватель, который соответствующим образом форматирует и отображает это содержимое. Так, результат выполнения следующего сценария будет тем же, что и в предыдущем примере:
<H3 ALIGN=CENTER> <% If blnFirstTime Then %> Welcome to the Overview Page. <% Else %> Welcome Back to the Overview Page. <% End If %> </H3>
Если результат возвращается только один раз или автору удобнее добавить инструкции к существующему HTML-тексту, воспользуйтесь чередованием команд сценария и HTML. Метод Response.Write используют в том случае, если нежелательно разрывать инструкцию на части с помощью разделителей или необходимо собрать строку, которая должна быть отправлена в обозреватель. Например, нетрудно сконструировать строку текста, которая заполняла бы строку таблицы значениями, присланными в форме HTML:
Response.Write "<TR><TD>" & Request.Form("FirstName") _
& "</TD><TD>" & Request.Form("LastName") & "</TD></TR>"
Request.Form возвращает значения, отправленные из HTML-формы (см. раздел Обработка сведений, введенных пользователем).
Примечание. В языке VBScript знак амперсанда (&) означает объединение строк. Символ подчеркивания (_) в языке VBScript означает продолжение строки.
Задание типа содержимого
Когда веб-сервер возвращает файл в обозреватель, передаются также данные о типе содержимого этого файла. Эти данные позволяют обозревателю определить, может ли он отобразить полученный файл непосредственно или для этого следует вызвать другое приложение. Например, если веб-сервер возвращает таблицу Microsoft Excel, то для отображения соответствующей страницы обозреватель должен обладать возможностью запуска копии приложения Microsoft Excel. Веб-сервер распознает типы файлов посредством сопоставления расширения имени файла со списком типов MIME (Multipurpose Internet Mail Extensions). Например, для запуска Microsoft Excel обозреватель должен распознать тип MIME «application/vnd.ms-excel».
Чтобы задать для отправляемого пользователю содержимого тип этого содержимого в HTTP-строке, можно использовать свойство ContentType объекта Response. Например, следующая команда задает тип содержимого для определений каналов:
<% Response.ContentType = "application/x-cdf" %>
Дополнительные сведения о каналах см. в части Создание динамических каналов в этом разделе.
Другими общими типами содержимого являются «text/plain» (для содержимого, которое возвращается как текст, а не как интерпретируемые инструкции HTML), «image/gif» (для изображений формата GIF), «image/jpeg» (для изображений формата JPEG), «video/quicktime» (для фильмов формата Apple QuickTime®), а также «text/xml» (для документов формата XML). Кроме того, веб-сервер или веб-обозреватель могут поддерживать специальные типы MIME. Чтобы узнать, какие типы содержимого уже определены данным веб-сервером корпорации Майкрософт, воспользуйтесь оснасткой Internet Information Services, откройте окно свойств данного веб-узла, щелкните вкладку Заголовки HTTP, а затем — вкладку Типы файлов. Эти типы файлов могут использоваться для справки в тех случаях, когда тип содержимого задается вручную с помощью ASP.
Перенаправление запросов обозревателя
Вместо отправки содержимого пользователю, имеется возможность перенаправить запрос обозревателя на другой адрес URL с помощью метода Redirect. Например, если необходимо обеспечить, чтобы пользователи обращались к данному приложению с домашней страницы, получив код клиента, можно проверять наличие у них этих кодов. При отсутствии такого кода пользователя можно перенаправить на домашнюю страницу.
<%
If Session("CustomerID") = "" Then
Response.Redirect "Register.asp"
End If
%>
Сценарии на стороне сервера называются буферизованными, если эти сценарии обрабатываются раньше, чем какое-либо содержимое отправляется пользователю. ASP позволяет включить или отключить буферизацию, причем эта настройка может значительно изменить работу метода Redirect. В частности, если буферизация отключена, запрос обозревателя необходимо перенаправить до того, как HTTP-заголовки данной страницы будут возвращены этому обозревателю.
Чтобы избежать возврата каких-либо данных в обозреватель, поместите инструкцию Response.Redirect в верхней части страницы перед текстом и тегами <HTML>. В случае вызова метода Response.Redirect после возврата содержимого или заголовков в обозреватель последует сообщение об ошибке. Кроме того, следует иметь в виду, что инструкция Response.Redirect не требует последующей инструкции Response.End.
Если инструкцию Response.Redirect нужно использовать в середине страницы, используйте эту инструкцию вместе со свойством Response.Buffer, как показано в части Буферизация содержимого данного раздела.
Передача данных между файлами .ASP
Для перенаправления запроса обозревателя с помощью метода Response.Redirect требуется двойной обмен, означающий, что сервер отправляет обозревателю HTTP-ответ с указанием расположения нового адреса URL. Обозреватель автоматически выходит из очереди запросов данного сервера и отправляет новый HTTP-запрос по указанному адресу URL. Затем сервер добавляет этот запрос в очередь запросов вместе с запросами других клиентов, поступившими за это время. Для веб-узлов с большой нагрузкой двойной обмен может сузить полосу пропускания и снизить производительность сервера, особенно в случае перенаправления обозревателя к файлу, расположенному на том же самом сервере.
Вместо метода Response.Redirect для передачи данных из одного файла .asp в другой файл на том же сервере можно использовать метод Server.Transfer. Этот метод обеспечивает непосредственную передачу запросов к файлам .asp без выхода из очереди запросов сервера и позволяет избежать затрат на двойной обмен.
Например, в следующем сценарии метод Server.Transfer используется для перехода между страницами приложения в зависимости от сведений о состоянии:
<%
If Session("blnSaleCompleted") Then
Server.Transfer("/Order/ThankYou.asp")
Else
Server.Transfer("/Order/MoreInfo.asp")
End if
%>
Метод Server.Transfer отправляет запросы из одного исполняемого файла .asp в другой. Во время передачи первоначально запрошенный файл .asp сразу же прекращает выполнение, но не очищает выходной буфер (дополнительные сведения см. в разделе Буферизация содержимого). Когда затем начинает выполняться конечный файл, он получает доступ к сведениям о запросе. Во время выполнения этот файл имеет доступ к тому же набору внутренних объектов (Request, Response, Server, Session и Application), что и первоначально запрошенный файл.
Кроме того, использование метода Server.Transfer допускается для передачи между файлами .asp, расположенными в различных приложениях. Тем не менее, при передаче в файл .asp, расположенный в другом приложении, этот файл будет вести себя так, как если бы он был часть приложения, которое начало передачу. Это означает, что указанный файл будет иметь доступ только к тем переменным, область определения которых задана для исходного приложения, а не того приложения, в котором этот файл фактически находится. Например, при передаче из файла, расположенного в приложении Sales, в файл, расположенный в приложении Personnel, приложение Sales фактически заимствует этот файл у приложения Personnel и исполняет его как часть приложения Sales.
ASP также предоставляет команду Server.Execute, с помощью которой можно осуществить передачу в файл, выполнить его содержимое, а затем вернуться в файл, который начал передачу. При наличии навыков программирования на языке VBScript удобно рассматривать Server.Execute как аналог вызова процедуры, за исключением того, что вместо выполнения процедуры выполняется файл .asp целиком.
Например, следующий сценарий демонстрирует возможности использования команды Server.Execute для выполнения динамического включения файлов .asp:
<%
.
.
.
If blnUseDHTML Then
Server.Execute("DHTML.asp")
Else
Server.Execute("HTML.asp")
End If
.
.
.
%>
При условии, что конечный файл принадлежит приложению на том же сервере, исходное приложение будет передавать в этот файл, выполнит его содержимое, а затем возобновит выполнение файла, начавшего эту передачу. Как и в случае метода Server.Transfer, выполняемый файл .asp действует так, как будто является частью исходного приложения. Однако метод Server.Execute не поддерживает передачу между серверами. Дополнительные сведения см. в разделе Server.Execute.
Буферизация содержимого
По умолчанию веб-сервер обрабатывает все команды сценариев на странице до того, как пользователю будет отправлено какое-либо содержимое. Этот процесс называется буферизацией. С помощью свойства Buffer объекта Response буферизацию можно отключить. В этом случае веб-сервер возвращает коды HTML и результаты сценариев по мере обработки страницы.
Буферизация файлов .asp имеет то преимущество, что пользователь получает возможность прервать отправку веб-страницы. Это может понадобиться, например, если сценарий работает неправильно или пользователь не располагает соответствующими учетными записями для безопасного доступа. Вместо буферизации можно отправить пользователя на другую страницу с помощью метода Server.Transfer или очистить буфер (с помощью метода Clear объекта Response), чтобы отправить пользователю другое содержимое. В зависимости от приложения, метод Clear может быть применен до передачи. В следующем примере используются оба этих метода:
<HTML>
<BODY>
.
.
.
<%
If Request("CustomerStatus") = "" Then
Response.Clear
Server.Transfer("/CustomerInfo/Register.asp")
Else
Response.Write "Welcome back " & Request("FirstName") & "!"
.
.
.
End If
%>
</BODY>
</HTML>
Кроме того, свойство Response.Buffer позволяет предотвратить возврат заголовка HTTP сервером до того, как сценарий сможет изменить этот заголовок. Некоторые свойства и методы, такие как Response.Expires и Response.Redirect, изменяют заголовок HTTP.
Если свойству Buffer в сценарии присвоено значение TRUE, а метод Flush не вызывался для немедленной отправки буферизованного содержимого в обозреватель, то сервер будет обслуживать запросы клиентов на открытые соединения. Преимущество этого стиля написания сценариев заключается в повышении производительности сервера за счет того, что не нужно создавать новое соединение для каждого запроса клиента (предполагается, что сервер, клиент и прокси-серверы поддерживают запросы на открытые соединения). Однако у такого подхода есть один возможный недостаток: буферизация не позволяет серверу ответить пользователю до тех пор, пока сервер не закончит обработку всего сценария. При работе с большими или сложными сценариями пользователям, возможно, придется долго ждать появления веб-страницы.
По умолчанию для приложений ASP буферизация включена. Имеется возможность с помощью оснастки Internet Information Services отключить буферизацию для всего приложения ASP. Дополнительные сведения см. в разделе Настройка приложений ASP.
Кэширование страниц на прокси-серверах
Приложение может отправлять страницы клиенту через прокси-сервер. Прокси-сервер выступает от имени обозревателей клиентов, запрашивая для них страницы на веб-узлах. Прокси-сервер кэширует HTML-страницы, чтобы при повторении запросов к одной и той же странице быстро и эффективно возвращать искомые данные в обозреватели. Использование прокси-серверов для обработки запросов и кэширования страниц позволяет уменьшить загрузку сети и веб-сервера.
Хотя кэширование хорошо работает со многими HTML-страницами, однако при обработке страниц ASP, содержащих часто обновляемые сведения, не редки сбои. Например, страницы, отображающие цены биржевого рынка или запасы комплектующих изделий при массовом производстве, должны показывать последние сведения. Задержка даже на один час может сделать данные недостоверными. Если приложение возвращает личные данные, например специальную домашнюю страницу, может потребоваться скрытие личных сведений каждого пользователя от остальных пользователей.
По умолчанию ASP дает команду прокси-серверам не кэшировать саму страницу ASP (хотя изображения, гиперкарты, минипрограммы и другие элементы, на которые есть ссылки на данной странице, продолжают кэшироваться). Имеется возможность разрешить кэширование определенных страниц с помощью свойства Response.CacheControl, которое в заголовке HTTP задает значение поля управления кэшированием. Значением Response.CacheControl по умолчанию является строка «Private», которая запрещает кэширование данной страницы прокси-серверами. Чтобы разрешить кэширование, задайте для поля управления кэшированием в заголовке значение «Public»:
<% Response.CacheControl = "Public" %>
Поскольку заголовки HTTP должны быть отправлены в обозреватель или прокси-сервер раньше, чем какое-либо содержимое страницы, необходимо либо поместить свойство Response.CacheControl перед всеми тегами HTML, либо включить буферизацию данной страницы с помощью свойства Response.Buffer, если буферизация отключена.
Поле заголовка для управления кэшированием является частью спецификации HTTP 1.1. Страницы ASP не кэшируются на прокси-серверах, поддерживающих только спецификацию HTTP 1.0, поскольку поле окончания срока действия в заголовке не отправляется.
Запрет кэширования страниц обозревателями
В каждой версии обозревателя действуют свои правила, определяющие кэширование страниц. Чтобы запретить кэширование страниц ASP в обозревателях, задайте заголовок окончания срока действия с помощью свойства Response.Expires:
<% Response.Expires = 0 %>
Значение 0 задает для кэшированных страниц немедленное окончание срока действия. Поскольку заголовки HTTP должны быть отправлены в обозреватель или прокси-сервер раньше, чем какое-либо содержимое страницы, необходимо либо поместить свойство Response.Expires перед всеми тегами HTML, либо использовать буферизацию данной страницы.
Создание динамических каналов
Канал — это веб-технология, доступная в обозревателе Microsoft Internet Explorer версии 4.0 или более поздней, которую можно использовать для автоматической доставки нового или обновленного содержимого веб-страниц пользователям. Канал заставляет компьютер пользователя периодически подключаться к серверу и извлекать обновленные сведения. (Этот процесс сбора данных обычно называют клиентским опросом, так как сведения «опрашиваются», или собираются, на сервере.) Когда новые сведения становятся доступными на отдельном веб-узле, соответствующее содержимое загружается в кэш обозревателя для просмотра в автономном режиме. Умелое использование каналов для распространения сведений посредством веб-страниц (особенно в интрасетях) может способствовать централизации данных и уменьшению нагрузки на сервер. Дополнительные сведения о каналах можно получить на веб-узле Microsoft Internet Explorer по адресу http://www.microsoft.com/windows/ie/.
С помощью ASP нетрудно написать сценарии, позволяющие динамически создавать каналы посредством формирования файла определения каналов. Файл определения каналов создается в формате XML (.cdf) и описывает организацию и расписание обновления содержимого канала. Синтаксис команд в файле .cdf аналогичен тегам HTML, поэтому эти команды нетрудно изучить и использовать в сценариях. При написании сценария на стороне сервера, предназначенного для создания файла определения каналов, присвойте соответствующему файлу расширение .cdx. Когда ASP читает файл с расширением .cdx, автоматически отправляется тип содержимого «application/x-cdf», который говорит обозревателю о том, что байты содержимого следует воспринимать как определения каналов. Если расширение .cdx не используется, в сценарии должен быть вручную задан тип содержимого «application/x-cdf». Для этого используют свойство Response.ContentType.
Ниже представлен пример возможного использования каналов. Следующая форма HTML предлагает пользователю выбрать каналы. При оправке форма автоматически вызывает сценарий, хранящийся в файле .cdx, чтобы создать определения каналов.
<P> Choose the channels you want. </P> <FORM METHOD="POST" ACTION="Chan.cdx"> <P><INPUT TYPE=CHECKBOX NAME=Movies> Movies <P><INPUT TYPE=CHECKBOX NAME=Sports> Sports <P><INPUT TYPE="SUBMIT" VALUE="SUBMIT"> </FORM>
Сценарий в файле Chan.cdx создает определения каналов на основе значений из формы, отправленных с помощью запроса.
<% If Request.Form("Movies") <> "" Then %>
<CHANNEL>
channel definition statements for the movie pages
</CHANNEL>
<% End If %>
<% If Request.Form("Sports") <> "" Then %>
<CHANNEL>
channel definition statements for the sports pages
</CHANNEL>
<% End If %>
Доступ к ресурсам сервера с помощью WebDAV
Протокол Distributed Authoring and Versioning (WebDAV) – это мощное расширение протокола HTTP 1.1, предоставляющее носители файлов, например файловую систему, по HTTP-соединению. WebDAV является многообещающей технологией с точки зрения превращения веб-пространства в непрерывную общую среду разработки. Используя реализацию WebDAV в IIS 5.0, можно предоставить удаленным разработчикам возможность создавать, удалять, перемещать, искать и устанавливать атрибуты файлов и каталогов на данном веб-сервере. Дополнительные сведения см. в разделе Публикация средствами WebDAV.