4341

Протокол HTTP. Унифицированные указатели ресурсов (URL)

Реферат

Информатика, кибернетика и программирование

Протокол HTTP В середине 90-х годов очень популярной стала WWW (WorldWideWeb) — Всемирная паутина. Это набор протоколов и программ для Интернета, представляющих информацию в гипертекстовом формате. Знаменитый браузер Mosaic...

Русский

2012-11-16

133.5 KB

8 чел.

Протокол HTTP

В середине 90-х годов очень популярной стала WWW (World Wide Web) — «Всемирная паутина». Это набор протоколов и программ для Интернета, представляющих информацию в гипертекстовом формате. Знаменитый браузер Mosaic, созданный в Национальном центре по применению супер-ЭВМ (National Center for Supercomputer Applications, NCSA), был первым графическим Web-браузером и способствовал популяризации WWW. Web разработана в 1989 году в Европейской лаборатории физики частиц (European Laboratory for Particle Physics, CERN) Тимоти Бернерсом-Ли (Timothy Berners-Lee). В настоящее время всеми стандартами, имеющими отношение к Web, ведает Консорциум World Wide Web (W3C).

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

Для упаковки и передачи данных в Web применяются протоколы MIME (Multipurpose Internet Mail Extensions) и TCP/IP (Transmission Control Protocol/Internet Protocol), а также и другие, например FTP и Telnet. Специально для Web разработаны указатели URL (Uniform Resource Locator), протокол HTTP (Hypertext transfer Protocol), язык HTML (Hyper-text Markup Language) и интерфейс CGI (Common Gateway Interface).

Унифицированные указатели ресурсов (URL)

Указатель URL (Uniform Resource Locator) — это адрес сетевого ресурса. Он похож на имя файла, но дополнительно содержит имя сервера и информацию о сетевом протоколе, используемом данным ресурсом. В некоторых случаях URL включает сведения об имени пользователя, а также специальные аргументы и параметры протокола.

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

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

Указатель URL состоит из следующих частей:

<схема>:<специальное_имя>

где <схема> — это название схемы (используемый протокол, например http, ftp и т. д.), а <специальное_имя> — имя в формате, зависящем от используемой схемы.

Многие URL имеют следующий формат:

<протокол>://<пользователь>:<пароль>@<хост>:<порт>/<путь>

где

  •  <пользователь> — это имя пользователя, если оно необходимо (например, для FTP с не анонимной регистрацией);
  •  <пароль> — пароль этого имени пользователя;
  •  <хост> — доменное имя хоста, например “fictionalcorp.com, или его IP-адрес в числовом формате вида х.х.х.х:
  •  <nopm> — номер IP-порта для соединения (если он не указан, используется стандартное значение для данного протокола);
  •  <путь> — связанные с URL данные, часто это указание подкаталога и имени файла.

Для Web-страницы URL выглядит, например, так:

http: //www.fictionalcorp.com/corpinfo/sales.html

  •  Фрагмент http указывает, что URL использует протокол HTTP;
  •  www.fictionalcorp.com — имя сервера, к которому желает подключиться пользователь;
  •  /corpinfo/sales.html — подкаталог и имя HTML-файла, хранящего Web-страницу.

Ниже перечислены некоторые популярные схемы:

  •  http  Протокол HTTP
  •  https Протокол HTTP, зашифрованный с помощью SSL (Secure Socket Layer)
  •  mailto Адрес электронной почты
  •  ftp  Протокол FTP
  •  news Новости Usenet
  •  file  Имена файлов определенного хоста
  •  telnet Интерактивный сеанс Telnet

Более короткий URL — http://www.fictionalcorp.com указывает на "основную страницу» этого сервера. Если явно не задано имя файла, то HTTP-серверы используют значение по умолчанию (часто это default.html или index.html). Приведенный URL можно преобразовать к более явному виду: http://www.fictiorialcorp.com/default.html.

Для протокола FTP применяется сходный синтаксис. Обращение к файлу bar.txt подкаталога /foo FТР-сервера ftp.fictionalcorp.com на языке URL выглядит следующим образом:

ftp://ftp.fictionalcorp.com/foo/bar.txt

Из-за огромной популярности World Wide Web в Интернете многие браузеры предполагают наличие префикса «http://» в URL, не содержащем явного указания протокола. Обычно имена доменов в явном виде содержат информацию о протоколе. Например, FТР-сервер компании называется ftp.fictionalcorp.com, а ее HTTP-сервер— www.fictionalcorp.com. Однако с появлением URL компания вправе использовать одно и то же имя fictionalcorp.com для обоих серверов. Тогда при использовании их ресурсов необходимо явно задавать соответствующий протокол, например ftp://fictionalcorp.com/public/foo.txt или http://fictionalcorp.com/

Частичный или относительный URL — тот, в котором не указан протокол, хост, порт или путь, а лишь относительное имя ресурса. Например, если Web-страница http://www.fictionalcorp.com/piiblic/foo/bar.html ссылается на bletch.html, это не что иное, как относительная форма от http://www.fictionalcorp. com/public/foo/bletch.html.

Как уже говорилось ранее, синтаксис URL меняется в зависимости от URL-схемы. Например, в протоколе HTTP символ «#» после имени HTML-файла обозначает точку привязки (закладку). Так, http://www.fic-tionafcorp.com/foo.html#disclaimer указывает на фрагмент disclaimer документа foo.html.

Вместо подкаталога и имени файла URL может содержать другую информацию о ресурсе. Так выгладит URL для протокола NNTP:

nntp://<хост>:<порт>/<группа_новостей>/<статья>

где <группа_новостей> — имя группы новостей, а <статья> — номер статьи.

Вообще говоря, в URL следует использовать только алфавитно-цифровые символы, так как большинство специальных символов зарезервированы или их прямое использование небезопасно. К первым относятся: «;», «/», «?», «:», «@», «=», «&». Ненадежные символы - «<», «>», «»»,«#», «%», «{», «}», «|», «\», « », «-», «[», «]», «'».

Если имя ресурса содержит зарезервированный символ или символ, не принадлежащий US-ASCII, то перед использованием в URL имя надо закодировать. При кодировании символ заменяется тремя новыми - знаком процента (%) и двумя шестнадцатеричными цифрами, представляющими код заменяемого символа.

Предпосылки

Протокол HTTP — основной и достаточно простой способ передачи данных между Web-сервером и клиентом. До появления Web и HTTP для передачи файлов в Интернете в качестве протокола ввода/вывода чаще всего применяли FTP.

HTTP — это компактный, быстрый протокол ввода/вывода, работающий с URL и предназначенный для сред гипертекст/гипермедиа. В отличие от FTP, это протокол без состояний и имеет лишь несколько команд (методов). Благодаря использованию MIME, HTTP приспосабливается ко многим форматам данных и различным задачам ввода/вывода.

HTTP — клиент-серверный протокол, реализующий модель запрос/ответ. HTTP-клиент, или пользовательский агент (обычно это Web-браузер), подключается к HTTP-серверу с помощью URL и запрашивает ресурс, например HTML-документ.

Для инкапсуляции данных в этой модели применяются расширения MIME. Структура данных, пересылаемых между клиентом и сервером, напоминает электронную почту. Она состоит из тела сообщения и метаданных (заголовков сообщений). Протокол HTTP передает информацию в формате MIME. Метаданные содержат информацию, необходимую для передачи данных между HTTP-сервером и клиентом. Однако HTTP допускает двоичный формат, чего обычный MIME (из-за 7-битных ограничений почтовых шлюзов) не позволяет.

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

Традиционно HTTP-клиенты и серверы общаются через 80-й порт TCP/IP, по умолчанию зарезервированный для HTTP. Однако могут использоваться и другие порты, явно указанные в URL. В дополнение замечу, что HTTP не предполагает применение именно TCP/IP и отлично функционирует с другими протоколами гарантированной доставки.

Web-браузер часто обрабатывает Web-страницы, состоящие из многих объектов, например, самого HTML-документа и нескольких изображений (GIF, JPEG, PNG и др.). Большинство HTTP-клиентов для чтения начального HTML-документа создают только один поток (с одним подключением к серверу), а затем еще несколько потоков (каждый с отдельным подключением к серверу) для получения остальных необходимых файлов. Соединение устанавливается по запросу клиента и разрывается после ответа сервера.

Принципы работы HTTP

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

1. Клиент устанавливает связь с сервером по назначенному номеру порта (по умолчанию - 80). Затем клиент посылает запрос документа, указав HTTP-команду, называемую методом, адрес документа и номер версии HTTP. Например, в запросе

GET /index.html HTTP/1.0

используется метод GET, которым с помощью версии 1.0 HTTP запрашивается документ index.html. Методы HTTP более подробно рассматриваются ниже.

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

User-Agent: Mozilla/4.05 (WinNT; 1)

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

Завершается заголовок пустой строкой.

3. Послав запрос и заголовки, клиент может отправить и дополнительные данные. Эти данные используются главным образом теми CGI-программами, которые применяют метод POST. Клиенты (например, Netscape Navigator-Gold), также могут использовать их для помещения отредактированной страницы обратно на Web-сервер.

Сервер отвечает на запрос клиента следующим образом:

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

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

НТТР/1.0 200 OK

говорит о том, что сервер для ответа использует версию HTTP 1.0. Код состояния 200 означает, что запрос клиента был успешным, и затребованные данные будут переданы после заголовков.

2. После строки состояния сервер передает клиенту информацию заголовка, содержащую данные о самом сервере и затребованном документе. Ниже приведен пример заголовка:

Date: Fri, 10 Jan 1998 08:17:58 GMT

Server: Apache/1.2.6

Last-modified: Mon, 12 Jun 1997 21:53:08 GMT

Content-type: text/html

Content-length: 2482

Завершает заголовок пустая строка.

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

В HTTP 1.0 за передачей сервером затребованных данных следует разъединение с клиентом, и транзакция считается завершенной, если не передан заголовок Connection: Keep Alive. В HTTP 1.1 сервер по умолчанию не разрывает соединение, и клиент может посылать другие запросы. Поскольку во многие документы встроены другие документы - изображения, кадры, апплеты и т.д., это позволяет сэкономить время и затраты клиента, которому в противном случае пришлось бы для получения всего одной страницы многократно соединяться с одним и тем же сервером. Таким образом, в HTTP 1.1 транзакция может циклически повторяться, пока клиент или сервер не закроет соединение явно.

HTTP не сохраняет информацию по транзакциям, поэтому в следующей транзакции приходится начинать все заново. Преимущество такого правила организации взаимодействия состоит в том, что HTTP сервер может обслужить в заданный промежуток времени гораздо больше клиентов, ибо устраняются дополнительные расходы на отслеживание сеансов от одного соединения к другому. Есть и недостаток: для сохранения информации по транзакциям более сложные CGI-программы должны пользоваться скрытыми полями ввода или внешними средствами, например "ключиками" (cookies) Netscape.

Запросы клиента

Запросы клиента разбиваются на три раздела. Первая строка сообщения всегда содержит HTTP-команду, называемую методом URI, который обозначает запрашиваемый клиентом файл или ресурс, и номер версии HTTP. Следующие строки запроса клиента содержат информацию заголовка. Информация заголовка содержит сведения о клиенте и информационном объекте, который он посылает серверу. Третья часть клиентского запроса представляет собой тело содержимого - собственно данные, посылаемые серверу.

URI (Uniform Resource Identifier, универсальный идентификатор ресурса) - это общий термин для всех допустимых форматов схем адресации, поддерживаемых в World Wide Web. Сейчас общепринятой является схема адресации с использованием универсальных локаторов ресурсов (URL).

Методы

Метод - это HTTP-команда, с которой начинается первая строка запроса клиента. Метод сообщает серверу о цели запроса. Для HTTP определены три основных метода: GET, HEAD и POST. Определены и другие методы, но они не так широко поддерживаются серверами, как три перечисленных (хотя эти другие методы в будущем будут использоваться более часто). При задании имен методов учитывается регистр, поэтому GET и get различаются.

Метод GET 

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

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

Тело информационного содержимого запроса GET всегда пустое. GET в переводе на человеческий язык означает примерно следующее: "Дайте мне этот файл". Для идентификации указанного в запросе клиента файла или программы обычно используется полное имя этого объекта на сервере.

Ниже приведен пример успешного запроса GET на получение файла. Клиент посылает запрос:

GET /index.html HTTP/1.О

Connection: Keep-Alive

User-Agent: Mozilla/4.05 (WinNT; 1)

Host: www.ora.com

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

Сервер отвечает:

HTTP/1.0 200 Document follows

Date: Fri, 20 Jan 1998 08:17:58 GMT

Server: Apache/1.2.6

Last-modified: Mon, 20 Jun 1997 21:53:08 GMT

Content-type: text/html

Content-length: 2482

(далее следует тело документа)

Метод GET используется также для передачи входной информации в CGI-программы посредством тегов форм. Поскольку тело запроса GET пусто, входные данные присоединяются к URL в строке GET запроса. Если в теге <form> задано значение атрибута method="GET", то пары ключ-значение, представляющие собой введенные из формы данные, присоединяются к URL после вопросительного знака. Пары отделяются друг от друга амперсандом (&). Например, по запросу

GET /cgi-bin/birthday.pl?month=august&date=24 HTTP/1.О

сервер передаст в CGI-программу birthday.pl значения month и date, указанные в форме, созданной на клиенте. Входные данные в конце URL кодируются в соответствии со спецификацией CGI. Чтобы специальные символы интерпретировались обычным образом, используются их шестнадцатеричные коды.

Аналогичным образом в методе GET может передаваться информация о дополнительных путях. При этом дополнительный путь указывается после URL, т.е. /cgi-bin/display.pl/cgi/cgi_doc.txt. Сервер определяет, где заканчивается имя программы (display.pl). Все данные, которые следуют за именем программы, интерпретируются как дополнительный путь.

Метод HEAD 

Метод HEAD аналогичен методу GET, за исключением того, что сервер ничего не посылает в информационной части ответа. Метод HEAD запрашивает только информацию заголовка о файле или ресурсе. Информация заголовка запроса HEAD должна быть такой же, как в запросе GET.

Этот метод используется, когда клиент хочет найти информацию о документе, не получая его. Для метода HEAD существует множество приложений. Например, клиент может затребовать следующую информацию:

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

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

Ниже приведен пример HTTP-транзакции с использованием запроса HEAD. Клиент посылает запрос:

HEAD /index.html HTTP/1.0

Connection: Close

User-Agent: Mozilla/4.05 (WinNT; 1)

Host: www.ora.com

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

Сервер отвечает:

HTTP/1.0 200 Document follows

Date: Fri, 20 Jan 1998 08:17:58 GMT

Server: Apache/1.2.6

Last-modified: Mon, 17 Jun 1996 21:53:08 GMT

Content-type: text/html

Content-length: 2482

(Тело содержимого в ответе на запрос HEAD не передается.)

Метод POST 

Метод POST позволяет посылать на сервер данные в запросе клиента. Эти данные направляются в программу обработки данных, к которой сервер имеет доступ (например, в CGI-сценарий). Метод POST может использоваться во многих приложениях. Например, его можно применять для передачи входных данных для:

  •  сетевых служб (таких как телеконференции);
  •  программ с интерфейсом в виде командной строки;
  •  аннотирования документов на сервере;
  •  выполнения операций в базах данных.

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

Ниже приведен небольшой пример запроса клиента с использованием метода POST. Клиент посылает на сервер данные о дне рождения, введенные в форму:

POST /cgi-bin/birthday.pl HTTP/1.0

User-Agent; Mozilla/4.05 (WinNT; 1)

Accept: image/gif, iinage/x-xbj.tmap, image/jpeg, J.mage/pjpeg, */*

Host: www.ora.com

Content-type: application/x-www-form-urlencoded

Content-Length: 20

month=august&date=24

Другие методы 

Приведенные ниже методы также определены, хотя и используются не столь часто:

LINK связывает информацию заголовка с документом на сервере.

UNLINK отменяет связь информации заголовка с документом на сервере.

PUT помещает тело содержимого запроса по указанному URI.

DELETE удаляет данные, находящиеся на сервере по заданному URI.

OPTIONS запрашивает информацию о коммуникационных параметрах сервера. Чтобы запросить данные обо всем сервере в целом, вместо URI запроса следует использовать символ *.

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

Ответы сервера

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

Коды состояния

Протокол HTTP определяет набор кодов состояния, которые должны быть понятны и клиенту и серверу, чтобы те могли успешно передавать сообщения. Коды разбиты на категории, перечисленные в ниже.

Информационные

100 - 199

Сообщения конкретных приложений

Успешные

200 - 299

Запрос успешно обработан

Перенаправление

300 - 399

Для обработки запроса требуются дополнительные действия клиента. Обычно они выполняются без участия пользователя

Ошибка клиента

400 - 499

Проблемы на стороне клиента

Ошибка сервера

500 - 599

Проблемы на стороне сервера

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

200

OK

Нет ошибки, запрос успешно обработан

201

Created

Выполнена команда POST

202

Accepted

Получен асинхронный запрос: он уже получен, но не обязательно обработан

204

No Content

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

300

Multiple Choices

Требуемый ресурс доступен из многих мест. В ответе возвращается список альтернатив. Предпочтительный выбор сервера включен в поле Location ответа.

301

Moved Permanently

Требуемый URL перемещен на новый URL (указанный в поле Location ответа). Все последующие ссылки на этот ресурс должны использовать новый URL.

302

Moved Temporarily

Требуемый URL временно перемещен на новый URL (указанный в поле Location ответа). Последующие ссылки на этот ресурс должны использовать старый URL

304

Not Modified

Выполнена команда «условный GET», однако, документ не изменялся со времени, указанного в поле If-Modified-Since

400

Bad Request

Запрос не распознан. Клиенту следует послать исправленный запрос

401

Unauthorized

Если запрос был анонимным, то его следует аутентифицировать. Если запрос был аутентифицирован, то это — отказ в доступе

403

Forbidden

Сервер отказывается обработать запрос. Обычная причина — нарушение прав доступа

404

Not found

Сервер не нашел указанный URL

500

Internal Server Error

Произошла непредвиденная ошибка сервера

501

Not Implemented

Сервер не поддерживает этот запрос

502

Bad Gateway

Прокси-сервер (или шлюз) получил неправильный ответ от сервера, к которому он подсоединен

503

Service Unavailable

Сервер временно недоступен или отказывается обработать запрос. Обычная причина — перегрузка сервера или его обслуживание.

Поля заголовка

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

Accept

В поле Accept перечислены возможные форматы данных при ответе на запрос. Большинство клиентов показывают допустимость всех форматов, водя в это поле звездочку (*). Нераспознанные форматы данных передаются пользователю с просьбой сопоставить их с некоторым MIME-типом.

Accept-Charset

Здесь перечислены наборы символов (помимо US-ASCII и ISO-8859-1), поддерживаемые клиентом.

Accept-Encoding

Это поле сходно с полем Accept, но описывает допустимые кодировки содержимого ответа.

Accept-Language

Это поле сходно с полем Accept, но указывает языки, допустимые в ответе.

Allow

В поле Allow перечислены поддерживаемые сервером команды (GET, HEAD и т. д.). Клиенту разрешено их использовать.

Authorization

Его применяют НТТР-серверы, не разрешающие анонимный доступ к некоторым ресурсам. В этом поле запроса передается «удостоверение личности» пользователя.

Для случаев, когда анонимный доступ невозможен, HTTP предоставляет простой механизм аутентификации типа «запрос-ответ». Допустимы различные механизмы аутентификации. В базовом для HTTP механизме аутентификации имя пользователя и пароль шифруются нестойким MIME-кодированием Base64. Некоторые HTTP-клиенты и серверы поддерживают другие, более безопасные методы.

В заголовок ответа, содержащего код «401 Unauthorized», сервер обязательно включает поле WWW-Authenticate, где описана причина отказа и поддерживаемые сервером методы аутентификации. После этого пользователь повторно передает запрос, заголовок которого содержит дополнительное поле Authorization с «удостоверением личности» для указанного механизма аутентификации. Если сервер не принимает это «удостоверение личности», то он отвечает кодом «403 Forbidden».

Content-Encoding

Здесь указан механизм кодирования (zip, compress и т. д.), который следует использовать для декодирования данных.

Content-Language

Здесь указан естественный язык предполагаемой аудитории.

Content-Length

Здесь определен размер тела переданного сообщения. В случае команды HEAD в этом поле указан размер данных, который имел бы место при использовании команды GET.

Content-Type

Здесь определен тип тела переданного сообщения. Для HTML-документов в этом поле обыкновенно находится «text/html». В случае команды HEAD в этом поле указан тип данных, который бы имел место при использовании команды GET.

Date

Здесь указаны дата и время создания сообщения.

Expires

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

From

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

If-Modified-Since

Это поле даты и времени используется командой GET для доступа к ресурсу только в том случае, если он был изменен. Это поле полезно для клиентов, применяющих кэширование. Если изменений нет, то возвращается код состояния «304 Not Modified».

Last-Modified

Здесь указана дата последнего изменения данных.

Link

Это поле позволяет устанавливать взаимосвязь данных с другим ресурсом, иерархической структурой или путями просмотра.

Location

В этом поле содержится точный URL прежнего местонахождения ресурса для случаев автоматического перенаправления (коды состояния 300-399).

MIME-Version

Содержит номер версии используемого протокола MIME.

Pragma

Это многоцелевое поле для директив конкретной реализации. Одной из распространенных директив является «no-cache», показывающая что данные не следует кэшировать.

Refer

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

Retry-After

Указывает интервал времени, в течение которого службы недоступны. Используется совместно с кодом состояния «503 Service Unavailable».

Server

Поле указывает название и версию HTTP-сервера.

Title

Поле указывает описательное имя объекта.

URI

Здесь перечислены некоторые или все унифицированные идентификаторы ресурсов URI (Uniform Resource Identifier), доступные для данного ресурса.

User-Agent

Поле указывает название и версию HTTP-клиента.

WWW-Authenticate

Реализует неанонимный доступ с аутентификацией типа «запрос/ответ». В этой схеме «удостоверение личности» не шифруется. Подробности — ранее в разделе «Authorization».

MIME-типы и подтипы

Указание (MIME) media-типа используется для передачи сведений о формате содержимого в HTTP-транзакциях. Клиенты используют MIME-типы в своих заголовках Accept для того, чтобы сообщить, в каких форматах они предпочитают принимать данные. Серверы используют MIME-типы в заголовках Content-Type, чтобы сообщить клиенту о том, в каком формате передается прилагаемое содержимое: то ли это HTML, который нужно форматировать, то ли это GIF или JPEG, требующий визуализации, то ли это данные в формате PDF, для которого нужно открывать внешнюю программу просмотра или использовать дополнительное приложение.

MIME (Multipurpose Internet Mail Extension) — многоцелевые расширения электронной почты для Internet), разработанные для обеспечения возможности передачи присоединенных данных по Internet средствами электронной почты. Из почтовых протоколов, в силу своей простоты и наглядности, расширения MIME перекочевали в HTTP. MIME-тип указывается в формате тип/подтип. Символ * используется как метасимвол; например, следующий заголовок клиента означает, что принимаются документы во всех форматах:

Accept: •"•/*

Следующий заголовок клиента означает, что принимаются все типы формата text независимо от подтипа:

Accept: text/*

Серверы и CGI-программы должны проверять данные о принимаемых типах, содержащиеся в заголовке Accept, и по возможности выдавать данные соответствующего типа. Большинство серверов определяют формат документа по суффиксу имени файла. Например, файлы с расширениями .htm и .html — это файлы в формате HTML, поэтому сервер посылает такой документ с типом text/html в заголовке Content-Type. При вызове CGI-программы серверу неизвестен формат возвращаемых данных, поэтому программа должна сообщить тип содержимого. По этой причине каждая CGI-программа должна включать в результат своей работы заголовок Content-Type, например:

Content-Type: text/html

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

Тип/Подтип

Обычное расширение

application/*

Используется для обозначения принадлежности данных какому-либо приложению. При этом application/octet-stream обычно используется для обозначения бинарных данных неизвестного типа.

application/msword

doc

application/octet-stream

bin

application/pdf

pdf

application/postscript

ai, eps, ps

application/rtf

rtf

application/sgml

sgml

application/x-tex

tex

application/zip

zip

application/x-wav

wav

image/*

Изображения различного типа

image/gif

gif

image/jpeg

jpeg, jpg, jpe

image/tiff

tiff, tif

multipart/*

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

multipart/alternative

multipart/digest

multipart/form-data

multipart/header-set

multipart/mixed

text/*

Текстовые данные с/без разметки

text/html

html, htm

text/plain

txt, rtx

video/*

видеопоток

video/mpeg

mpeg, mpg

Протокол HTTP 1.1

В настоящее время используется версия 1.1 протокола HTTP. Ее поддерживают все основные клиенты (браузеры) и Web-серверы. Протокол HTTP 1.1 описан в RFC 2068 и превосходит предыдущую версию — HTTP 1.0, — прежде всего, по производительности.

Однако есть и другие отличия, некоторые из них описаны ниже.

  •  Постоянные соединения. Протокол HTTP 1.1 устанавливает меньше TCP-соединений, чем HTTP 1.0. Версия 1.0 устанавливает и разрывает TCP-соединение для каждого HTML-запроса, a HTTP 1.1 создает TCP-соединение, сохраняющееся на протяжении многих запросов. Это также позволяет передавать несколько запросов в одном ТСР-сегменте. Постоянные соединения обеспечивают более высокую производительность, чем расширение Netscape под названием HTTP «Keep Alive», так как они лучше работают с прокси-серверами.
  •  Протокол HTTP 1.1 поддерживает сжатие данных. Это означает, что файлы между клиентом и сервером могут передаваться сжатыми, что снижает нагрузку на сеть.
  •  Создание виртуальных хостов. Протокол HTTP 1.1 позволяет одному Web-серверу (с одним IP-адресом) иметь несколько доменных имен. В настоящее время эта ситуация распространена достаточно часто, например, когда поставщик услуг Интернета содержит несколько доменов.
  •  Протокол HTTP 1.1 поддерживает многие языки.
  •  Протокол HTTP 1.1 поддерживает выборочную передачу, что подразумевает пересылку только выделенного участка файла или документа. Это особенно полезно при потере TCP-соединения, так как не приходится отправлять весь документ заново — передача возобновляется с последней контрольной точки.


 

А также другие работы, которые могут Вас заинтересовать

21937. РОЗВЯЗАННЯ ІНЖЕНЕРНИХ ЗАДАЧ ПО ТОПОГРАФІЧНИМ КАРТАМ ТА ПЛАНАМ 1.23 MB
  Довжина горизонтального прокладання лінії на місцевості визначиться за формулою Д = dпл М.1 Довжину нахиленої лінії місцевості L визначають за формулою 3. Якщо виміряно горизонтальне прокладання Д лінії на місцевості то її довжину на топографічному плані визначають за формулою .3 Довжину ламаної лінії рис.
21938. Розв’язання інженерних задач по топографічним картам та планам 324.5 KB
  Це і читання карти визначення координат висот дирекцій них кутів та ін. Визначення меж водозбірної площі Водозбірною площею називають поверхню землі з якої за умовами рельєфу збирається поверхнева вода в даний водостік річку логовину яр і т. Визначення меж водозбірної площі 22. Визначення площ Вимірювання площ ділянок місцевості виконується по топографічним картам та планам – графічним аналітичним та механічним способами.
21939. Оцінювання точності геодезичних вимірювань 207.5 KB
  Сукупність що впливають на результати вимірів називають комплексом умов: 1 об’єкт; 2 суб’єкт; 3 прилад; 4 метод; 5 зовнішнє середовище. При порушенні комплексу умов результати вимірів називають нерівноточними. Результати вимірів розглядають з точки зору кількісних та якісних характеристик. Математична обробка результатів вимірів дає можливість отримати як кількісні так і якісні характеристики.
21940. Вимірювання кутів 2.34 MB
  2: вертикальна вісь обертання теодоліта ZZ; вісь візування зорової труби VV; вісь обертання зорової труби НН; вісь циліндричного рівня LL; площина горизонтального кутовимірного круга ГК; площину вертикального кутовимірного круга ВК. П – з прямим зображенням зорової труби; М – маркшейдерське виконання; А – з автоколімаційним окуляром. 1 – зорова труба; 230 – вертикальний круг; 329 – колонки труби; 426 – горизонтальний круг; 522 – підставка теодоліта; 623 – підйомний гвинт; 724 – платформа; 8 – становий гвинт; 9 –...
21941. Загальні відомості. Системи координат в геодезії 130.5 KB
  Геодезія вивчає фігуру і розміри Землі зображення її поверхні на планах і картах виконання вимірювань необхідних для розв’язання різноманітних задач народного господарства та оборони країни. Розв’язання надзвичайно складних завдань привело до поділу геодезії на: Вищу геодезію – яка вивчає фігуру і розміри Землі її гравітаційне поле визначення координат точок земної поверхні. Супутникову геодезію – яка розглядає методи розв’язання геодезичних задач за допомогою штучних супутників Землі. Фотограмметрію і дистанційне зондування Землі –...
21942. Топографічні карти та плани 5.78 MB
  Топографічні карти та плани На попередній лекції ми розглянули геодезію як науку про Землю. Масштаби топографічних карт і планів Масштабом топографічної карти або плану називають відношення довжини лінії на карті плані до відповідної горизонтальної довжини цієї лінії на місцевості.5 де М – число яке показує ступінь зменшення ліній місцевості на карті плані і навпаки – ступінь збільшення ліній карти плану на місцевості тобто: на карті 2.7 Чим менший знаменник М чисельного...
21943. ОПОРНІ ГЕОДЕЗИЧНІ МЕРЕЖІ 2.87 MB
  Для зменшення впливу похибок вимірювань на точність визначення координат пунктів геодезичної мережі її створюють €œвід загального до часткового€. За цим принципом в Україні геодезична мережа поділяється на: державну геодезичну мережу; мережі згущення; знімальні мережі. Планові геодезичні мережі створюють способами: Астрономічний спосіб – полягає в визначені широти  довготи  кожного пункту та астрономічного азимута напрямів ліній геодезичної мережі за спостереженнями небесних світил.
21944. Топографічні знімання 9.53 MB
  Топографічні знімання Ми розглянули які виміри виконуються в геодезії як оцінити кількісні та якісні характеристики вимірів. Види знімань місцевості Процес виконання геодезичних вимірів для складання карт і планів місцевості називається зніманням. Якщо при зніманні визначають взаємне розміщення предметів та контурів місцевості то його називають горизонтальним або контурним зніманням. Знімання ситуації та рельєфу місцевості називають топографічним.