Интегрированные сети ISDN
Блок-схема канала HIPPI
Рисунок 4.1.7.4. Блок-схема канала HIPPI
Существуют документы, регламентирующие работу системы передачи информации HIPPI для основных уровней интерфейса, начиная с физического. Предусмотрена работа HIPPI с протоколами TCP/IP. Смотри также "ARP and IP Broadcast over HIPPI-800". J.-M. Pittet. May 2000, RFC-2834, "IP and ARP over HIPPI-6400 (GSN)". J.-M. Pittet. May 2000, RFC-2835.
Disconnected operation (работа в отключенном от сети состоянии)
12 Disconnected operation (работа в отключенном от сети состоянии)
Следует включать, если кэш намерено отключен от остальной сети на определенный период времени.
Формат i-поля пакета HIPPI
Рисунок 4.1.7.3. Формат i-поля пакета HIPPI
Поле L=1 – локально заданный формат; W=1 указывает на 64-битное соединение; D=1 отмечает смену положения адресов отправителя и получателя; PS – биты выбора пути (path selection); С – задержка вызова при занятой линии (camp-on; переключатель не разрывает соединения при занятом получателе, а ждет его освобождения). 12-битовые адреса отправителя и получателя часто делятся на 6-битовые секции, определяющие адрес переключателя и номер порта. HIPPI-IPI (intelligent peripheral interface) представляет собой быстродействующий интерфейс периферийных устройств, выполняющий команды SCSI. Расширение HIPPI-LE (link encapsulation) обеспечивает поддержку IEEE 802.2.
При расстояниях до 25 метров используется кабель, содержащий 50 скрученных пар. Такты часов следуют с периодом 40 нсек. В сетях HIPPI предусмотрен транзит пакетов формата TCP/IP. Блок-схема канала HIPPI показана на Рисунок 4.1.7.4.
Гипертекстный протокол HTTP
4.5.6.1 Гипертекстный протокол HTTP
/p> Протокол передачи гипертекста HTTP является протоколом прикладного уровня для распределенных мультимедийных информационных систем. Это объектно-ориентированный протокол, пригодный для решения многих задач, таких как создание серверов имен, распределенных объектно-ориентированных управляющих систем и др.. Структура HTTP позволяет создавать системы, независящие от передаваемой информации.
Протокол HTTP использован при построении глобальной информационной системы World-Wide Web (начиная с 1990).
Первые версии, такие как HTTP/0.9, представляли собой простые протоколы для передачи данных через Интернет. Версия HTTP/1.0, описанная в RFC-1945 [6], улучшила протокол, разрешив использование сообщений в формате MIME, содержащих метаинформацию о передаваемых данных, и модификаторы для запросов/откликов. Дальнейшее развитие сетей WWW-серверов потребовало новых усовершенствований, которые вряд ли являются последними.
Реальные информационные системы требуют больших возможностей, чем простой поиск и доставка данных. Для описания характера, наименования и места расположения информационных ресурсов введены: универсальный идентификатор ресурса URI (Uniform Resource Identifier), универсальный указатель ресурса URL и универсальное имя ресурса URN. Формат сообщений сходен с используемыми в электронной почте и описанный в стандарте MIME (Multipurpose Internet Mail Extensions).
HTTP используется также в качестве базового протокола для коммуникации пользовательских агентов с прокси-серверами и другими системами Интернет, в том числе и использующие протоколы SMTP, NNTP, FTP, Gopher и Wais. Последнее обстоятельство способствует интегрированию различных служб Интернет. Ниже описаны базовые понятия и термины протокола HTTP.
Прокси
Промежуточная программа, которая выполняет функции, как сервера, так и клиента. Такая программа предназначена для обслуживания запросов так, как если бы это делал первичный сервер. Запросы обслуживаются внутри или переадресуются другим серверам.
Туннель
Промежуточная программа, которая работает как ретранслятор между двумя объектами.
Туннель закрывается, когда обе стороны, соединенные им прерывают сессию. Туннель может быть активирован с помощью HTTP-запроса.
Время пригодности объекта (expiration time)
Время, при котором исходный сервер требует, чтобы объект не посылался более кэшем без перепроверки пригодности.
Эвристическое значение времени жизни (heuristic expiration time)
Время пригодности, присваиваемое объекту в кэше, если это время не задано явно.
Возраст
Возраст отклика – время с момента его посылки или проверки его пригодности исходным сервером.
Время жизни (freshness lifetime)
Продолжительность времени с момента генерации отклика до истечения его пригодности.
Свежий
Отклик считается свежим, если его возраст не превысил времени его пригодности.
Устаревший
Отклик считается устаревшим, когда его возраст превысил время жизни.
Семантическая прозрачность
Кэш по отношению к конкретному отклику функционирует в “семантически прозрачном” режиме, когда его использование не имеет последствий ни для исходного сервера, ни для запрашивающего клиента. Когда кэш семантически прозрачен, клиент получает в точности тот же отклик (за исключением транспортных заголовков), какой он бы получил при непосредственном обращении к исходному серверу.
Валидатор
Протокольный элемент (например, метка объекта или время last-modified), который используется для выяснения того, является ли запись в кэше эквивалентной копией объекта.
Метод
Процедура, выполняемая над ресурсом (get, put, head, post, delete, trace и т.д.).
Heuristic expiration (эвристическое завершение периода пригодности)
13 Heuristic expiration (эвристическое завершение периода пригодности)
Должно включаться, если кэш эвристически выбрал время жизни больше 24 часов, а возраст отклика превышает эту величину.
Язык HTML
4.5.6.2 Язык HTML
| 1. | Синтаксис HTML | |
| 2. | Описания атрибутов | |
| 2.1. | Булевы атрибуты | |
| 3. | HTML и URL | |
| 4. | Элементы, используемые в тексте документа | |
| 5. | Идентификаторы элементов. id и атрибуты классов. | |
| 5.1. | Элемент HTML | |
| 5.2. | Группирующие элементы div и span | |
| 5.3. | Элементы заголовков h1, h2, h3, h4, h5, h6 | |
| 5.4. | Элементы address | |
| 6. | Спецификация языка содержимого документа. Атрибут lang | |
| 7. | Наследование языковых кодов | |
| 8. | Спецификация направления текста. Атрибут dir | |
| 9. | Текст | |
| 9.1. | Структурированный текст | |
| 9.2. | Цитирование. Элементы q и blockquote | |
| 9.3. | Верхние и нижние индексы. Элементы sub и sup | |
| 9.4. | Строки и параграфы | |
| 9.4.1. | Параграфы и элемент p | |
| 9.5. | Элемент br | |
| 9.6. | Предварительно сформатированный текст. Элемент pre | |
| 10. | Пометка изменений документа. Элементы ins и del | |
| 11. | Формат даты и времени | |
| 12. | Неупорядоченные (ul) и упорядоченные (ol) списки | |
| 12.1. | Списки, форматируемые визуальным агентом пользователя | |
| 12.2. | Списки определений. Элементы dl, dt и dd | |
| 13. | dir и элементы menu | |
| 14. | Таблицы | |
| 14.1. | Структура таблиц | |
| 14.1.1. | Элемент table | |
| 14.2. | Вычисление числа рядов и колонок в таблице | |
| 14.3. | Ориентация таблиц | |
| 14.4. | Надписи и таблицы. Элемент caption | |
| 14.5. | Группы рядов. Элементы thead, tfoot | |
| 14.6. | Опционные метки групп рядов | |
| 14.7. | Группы колонок. Элементы colgroup и col | |
| 14.8. | Элемент col | |
| 14.9. | Ряды таблицы. Элемент tr | |
| 14.10. | Ячейки таблицы. Элементы th и td | |
| 14.11. | Ячейки, которые занимают несколько рядов или колонок | |
| 14.12. | Горизонтальное и вертикальное выравнивание | |
| 14.13. | Границы и линии | |
| 15. | Информация о пути. Элемент base | |
| 15.1. | Связи и якоря | |
| 15.2. | Элементы, определяющие якоря | |
| 15.3. | Элемент А | |
| 15.4. | Связи mailto | |
| 15.5. | Вложенные связи | |
| 15.6. | Якоря с атрибутом id | |
| 15.7. | Элемент link | |
| 15.8. | Типы связей | |
| 15.9. | Связи с поисковыми системами | |
| 16. | Элемент object | |
| 16.1. | Инициализация объекта. Элемент param | |
| 17. | Изображения. Элемент img | |
| 18. | Введение аплетов. Элемент applet | |
| 19. | Введение HTML-документа в другой HTML-документ | |
| 20. | Введение карты изображения в HTML-документ | |
| 20.1. | Карты изображения клиента | |
| 20.2. | Карты изображения клиента с map и area | |
| 21. | Визуальное представление изображений, объектов и аплетов | |
| 22. | Как специфицировать альтернативный текст? | |
| 23. | Стилевые листы | |
| 23.1. | Стилевая информация заголовка. Элемент style | |
| 23.2. | Типы среды | |
| 23.3. | Внешние стилевые листы | |
| 23.4. | Установка именованного стиля по умолчанию | |
| 23.5. | Форматирование | |
| 23.6. | Плавающие объекты | |
| 23.7. | Элементы управления шрифтами: tt, i, b, big, small, strike, s и u | |
| 23.8. | Элементы модификаторов шрифтов: font | |
| 23.9. | Элемент hr | |
| 24. | Рамки (frames) | |
| 24.1. | Элемент frameset | |
| 24.2. | Элемент frame | |
| 24.3. | Установка для связей адресов по умолчания | |
| 24.4. | Элемент noframes | |
| 24.5. | Элемент iframe | |
| 25. | Формы | |
| 25.1. | Элемент form | |
| 25.2. | Элемент input | |
| 25.3. | Элемент isindex | |
| 25.4. | Элемент button | |
| 25.5. | Элемент select | |
| 25.6. | Элемент optgroup | |
| 25.7. | Элемент textarea | |
| 25.8. | Элемент label | |
| 25.9. | Элементы fieldset и legend | |
| 26. | Выделение элементов | |
| 27. | Скрипты | |
| 27.1. | Элемент script | |
| 27.2. | Локальная декларация языка скрипта | |
| 27.3. | Ссылки на HTML-документы из скрипта | |
| 28. | Динамическая модификация документов | |
| 28.1. | Элемент noscript | |
| 28.2. | Комментирование скриптов в javascript | |
| 28.3. | Комментирование скриптов в vbscript | |
| 28.4. | Комментирование скриптов в tcl | |
| 29. | Верификация документов | |
| 29.1. | Каталог образцов sgml | |
| 29.2. | sgml декларация HTML 4.0 | |
| 29.3. | sgml декларация | |
| 29.4. | Определение типа документа dtd (document type definition) | |
| 30. | Определение типа документа frameset | |
| 31. | Эталонные символьные объекты в HTML 4.0 | |
| 31.1. | Введение | |
| 31.2. | Эталонные символьные объекты для символов ISO 8859-1 | |
| 32. | Приложение А. (Отличия HTML 3.2 и HTML 4.0) | |
| 33. | Приложение b: Рабочие характеристики, приложения и заметки для разработчиков | |
| 33.1. | Замечания по поводу некорректных документов | |
| 34. | Специальные символы в значениях атрибута uri | |
| 34.1. | Не-ascii символы в значениях атрибута uri | |
| 34.2. | Символ & в значениях атрибута uri | |
| 35. | Замечания об использовании sgml | |
| 36. | Спецификация не HTML данных | |
| 37. | Особенности sgml с ограниченной поддержкой | |
| 38. | Булевы атрибуты | |
| 39. | Помеченные секции | |
| 40. | Заметки по индексному поиску | |
| 40.1. | Определение языка документа | |
| 41. | Поисковые роботы | |
| 41.1. | Роботы и элементы meta | |
| 42. | Замечания о таблицах | |
| 43. | Динамическое реформатирование | |
| 44. | Инкрементное отображение | |
| 45. | Структура и презентация | |
| 46. | Группы строк и колонок | |
| 47. | Доступность | |
| 48. | Рекомендуемые алгоритмы верстки | |
| 49. | Фиксированные алгоритмы верстки | |
| 50. | Алгоритм авто выкладки | |
| 51. | Замечания о формах | |
| 52. | Будущие проекты | |
| 53. | Заметки о скриптах | |
| 53.1. | Зарезервированный синтаксис для будущих скриптов | |
| 54. | Замечания о доступности | |
| 55. | Замечания о безопасности | |
| 55.1. | Соображения безопасности для форм | |
| 56. | Ссылки на литературу и серверы |
/p> Язык программирования HTML ( Hypertext Markup Language) предназначен для создания гипертекстных документов, формат которых не зависит от ЭВМ или используемой ОС. HTML-документы являются SGML-документами (Standard Generalized Markup Language, [ISO 8879]) с семантикой, пригодной для представления информации от широкого круга доменов. Файлы HTML-документов должны иметь расширение .html или .htm. Данный формат пригоден для представления почтовых сообщений, новостей, меню, опций, гипермедийных документов, результатов запросов к базам данных, графических документов и т.д.
HTML используется во всемирной информационной системе World Wide Web (WWW) с 1990 года (разработчик Tim Berners-Lee).
В настоящее время существует также простой диалект языка SGML - XML (Extensible Markup Language). Смотри http://win.www.citycat.ru/doc/html/xml/wd-xml-lang или www.w3.org/put/www/tr (первоисточник). Предполагается, что этот язык совместим с SGML и HTML (последнее справедливо лишь частично).
Любое приложение SGML состоит из нескольких частей:
SGML-декларация определяет, какие символы и разделители могут быть использованы в приложении.
dtd (document type definition) определяет стандарт на типы документов и задает синтаксис базовых конструкций.
Спецификация семантики, которая может также включать определенные ограничения на синтаксис, не включенные в DTD и т.д. …
SGML – это система описания языков разметки (markup). HTML – пример такого языка. Каждый язык разметки, определенный в SGML, называется приложением SGML. HTML 4.0 является приложением SGML, соответствующим международному стандарту international standard ISO 8879:1986 -- Standard Generalized Markup Language SGML (определено в [ISO8879]).
Приложение SGML характеризуется:
Декларацией SGML. SGML-декларация специфицирует, какие символы и разграничители могут использоваться в приложении.
Описанием типа документа DTD (Document Type Definition). DTD определяет синтаксис конструкций разметки. DTD может включать в себя дополнительные определения, такие как эталонные символьные объекты (entity).
Спецификацией, которая описывает семантику разметки. Эта спецификация также определяет синтаксические ограничения, которые не могут быть выражены в рамках DTD.
Примерами документов, содержащих данные и разметку. Каждый пример содержит ссылку на DTD, которая используется для его интерпретации.
HTML предоставляет разработчику следующие возможности:
Публиковать в реальном масштабе времени документы с заголовками, текстом, таблицами, рисунками, фотографиями и т.д.
Одним нажатием клавиши мышки извлекать документы через гипертекстные связи.
Конструировать формы (бланки) для осуществления удаленных операций, для заказа продуктов, резервирования билетов или поиска информации.
Включать электронные таблицы (напр. Excel), видеоклипы, звуковые клипы и другие приложения непосредственно в документ.
1. Синтаксис HTML
Символьные объекты (entity) представляют собой цифровые или символьные имена символов, которые могут быть включены в документ HTML. Эти объекты нужны в тех случаях, когда прямой их ввод по каким-либо причинам невозможен. Эти объекты начинаются с символа & и завершаются точкой с запятой (;).
Элементы в SGML представляют собой структуры или описывают требуемое поведение. Элементы начинаются со стартовой метки (TAG), за которой следует содержание, и завершаются конечной меткой. Стартовая метка обычно записывается как <имя_элемента>, а конечная метка, как </имя_элемента>. Некоторые элементы могут не иметь содержания или конечной метки. “Пустые” элементы не имеют конечной метки. Имена элементов обычно записываются прописными буквами, но HTML использование прописных или строчных букв в именах элементов не регламентировано.
Атрибуты. Элементы могут иметь определенные свойства, эти свойства характеризуются атрибутами, которым пользователь может присваивать некоторые значения. Пары атрибут/значение должны быть записаны до появления закрывающей угловой скобки (>) стартовой метки. Если используется несколько атрибутов/значений, они разделяются пробелами.
Порядок их записи не играет роли. По умолчанию SGML требует, чтобы значения были помещены в двойные или одинарные кавычки. Для этих же целей могут использоваться символьные объекты " или " для двойной кавычки и ' для одинарной кавычки. Значения могут содержать помимо латинских букв и цифр символы (-) и (.). Имена атрибутов не чувствительны к тому, прописными или строчными буквами они напечатаны (как правило, их имена записываются в HTML строчными буквами).
Агент пользователя HTML – любой прибор, который интерпретирует HTML документы. К агентам пользователей относятся визуальные броузеры (текстовые и графические), не визуальные броузеры (звуковые и Брейля), поисковые роботы и т.д.. Агент пользователя должен игнорировать любые не узнанные атрибуты.
Пользователь – лицо, взаимодействующее с агентом пользователя, для того чтобы тем или иным способом ознакомиться с документом HTML.
URI. Любой ресурс в WWW – HTML документ, изображение, видео-клип, программа и пр. имеют адрес, который может быть представлен в виде универсального идентификатора ресурса (URI).
Комментарии в HTML имеют следующий синтаксис:
<!-- Комментарий -->
<!-- Если комментарий занимает более одной строки,
то он записывается так -->
dtd-комментарии выделяются двумя черточками (--) в начале и в конце текста.
HTML DTD начинается с серии описаний каких-то объектов (entities). Описание объекта представляет собой макрос, который может быть развернут где-либо в DTD(в HTML не применим). Когда макрос вызывается (по имени), он разворачивается в строку.
Описание объекта (entity) начинается с ключевого слова <!entity %, за которым следует имя объекта и помещенная в кавычки строка, которая разворачивается. Описание завершается символом >. Развертываемая строка может содержать другие имена объектов. Конкретные значения объекта начинаются с символа “%” и завершается опционно символом “;”. Эти объекты будут также развернуты (если требуется рекурсивно). Например:
<!entity %fontstyle “tt | i | b | big | small”>
<!entity %inline “#pcdata | %fontstyle; | %phrase; | %formctrl;”>
Большая часть HTML DTD состоит из описаний элементов и их атрибутов. Ключевое слово <!element> открывает описание элемента, а символ > - завершает. Между ними размещается имя элемента, две черточки после имени указывают на то, что стартовая и конечная метки являются обязательными. Одна черточка после имени элемента и последующая буква О указывают на то, что конечная метка может отсутствовать. Две буквы О означают допустимость отсутствия как стартовой, так и конечной метки. После имени может следовать содержимое элемента, которое называется моделью содержимого. Элементы без содержимого называются пустыми (empty). Пустые элементы описываются ключевым словом “empty”. Например, <!element ccc – o empty>. ccc – имя элемента; - О говорит о допустимости отсутствия конечной метки. В сочетании с моделью empty это означает, что конечная метка должна отсутствовать.
Модель содержимого описывает то, что может содержать элемент. Определения содержимого могут включать:
Имена допустимых и запрещенных элементов.
dtd-объекты.
Текст документа, отмеченный SGML-конструкцией “#pcdata”. Текст может содержать цифровые и именные символьные объекты.
Модель содержимого имеет следующий синтаксис.
| (…) | специфицирует группу. |
| А|b | Допускается присутствие А и В в любом порядке. |
| А,В | А должно появиться раньше, чем В. |
| a&b | a и b должны появиться только один раз, но в любом порядке. |
| А? | А может появиться не более одного раза. |
| А* | А может появиться любое число раз, включая 0. |
| А+ | А может появиться один или более раз. |
<!element select - - (option+)>
Элемент select должен содержать один или более элементов option.
<!element dl - - (dt|dd)+>
Элемент dl должен содержать один или более dt или dd элементов в любом порядке.
<!element option – o (#pcdata) *>
Элемент option может содержать только текст и символьные объекты.
2. Описания атрибутов
Описание атрибутов начинается с ключевого слова <!attlist>. Описание атрибута включает в себя:
Имя атрибута.
Тип значения атрибута или набор возможных значений.
Значение атрибута может быть определено тремя способами. Когда значение атрибута по умолчанию задано неявно (ключевое слово “#implied”), оно должно быть задано агентом пользователя или наследуется из определения порождающего элемента. Возможны также ключевые слова “#required” (всегда необходимо) и “#fixed” - присвоено фиксированное значение.
Рассмотрим описание элемента map с опционным атрибутом.
<!attlist map name cdata #implied >, здесь тип допустимого значения задан DATA (тип данных SGML). CDATA – представляет собой текст, который может содержать символьный объекты.
Описания атрибутов могут содержать объекты DTD. Например:
| <!attlist link %attrs; | -- id, class, style, lang, dir, title – |
| bref %url @implied | -- url для подключенного ресурса -- > |
| <!attrlist p | id id #implied -- уникальный идентификатор для данного документа -- | |
| class cdata #implied | -- список значений классов -- | |
| style cdata #implied | -- информация о стиле -- | |
| title cdata #implied | -- рекомендуемые заголовки/расширения -- | |
| lang name #implied | -- [rfc1766] код идентификатор языка -- | |
| dir (ltr|rtl) #implied | -- direction for weak/neutral text -- | |
| align (left|center|right|justified) #implied > |
<!entity % URL “CDATA” -- термин URL означает атрибут, значение которого равно универсальному указателю ресурса URL (uniform resource locator), см. RFC-1808 и RFC-1738 -->
2.1. Булевы атрибуты
Некоторые атрибуты выполняют роль булевых переменных. Их появление в стартовой метке элемента предполагает, что значение атрибута равно “true” (истинно). Их отсутствие означает, что их значение равно “false” (ложно). В HTML допускается сжатая форма записи булевых атрибутов:
<option selected> вместо
<option selected=”selected”>.
3. HTML и URL
World Wide Web (WWW) представляет собой всемирную сеть информационных ресурсов. WWW базируется на трех механизмах, которые обеспечивают доступ к этим ресурсам:
Однородная схема имен для описания положения ресурсов в сети WWW(например, URI).
Протоколы доступа к именованным ресурсам через WWW-сеть (напр., HTTP).
Гипертекст, который обеспечивает простую технику поиска и перемещения (навигации) в сетях WWW (например, HTML).
Каждый ресурс, доступный в WWW (HTML-документ, видео-клип, программа или статическое изображение) имеет адрес, который кодируется с помощью универсального идентификатора ресурса universal resource identifier, или uri. URI состоит из трех частей:
Схема имен механизмов доступа к ресурсам [см. RFC-2068; далее в тексте данного документа ссылки на публикации и сервера, представленные в конце выделены квадратными скобками [].].
Имя машины, где размещается ресурс.
Имя самого ресурса в виде прохода к нему (path).
Примером URI может служить адрес, где размещено описание языка HTML v4.0:
http://www.w3.org/tr/rec-html4/
Этот URI можно воспринимать следующим образом: имеется документ, доступный через протокол HTTP (см. [RFC-2068]), этот документ находится на ЭВМ www.w3.org, проход к нему имеет вид /tr/rec-html4/.
Замечание. Большинство читателей знакомо с термином URL (Universal Resource Locator; [RFC-1738]) URL представляет собой подмножество более общей системы имен URI.
Следует помнить, что запись URL чувствительна к тому, строчные или прописные буквы используются при его написании (это не относится только к имени ЭВМ).
Спецификация URL определяет положение документа в сети, но не позицию внутри документа. По этой причине введено понятие URL-фрагмента, который может указывать на определенную часть документа. URL-фрагмент завершается символом #, за которым следует идентификатор указателя (anchor). Примером такого URL-фрагмента может служить http://store.in.ru/semenov/intro.htm#intr_1, где int_1 - имя метки в тексте документа intro.htm.
Для локальной адресации HTML- документов используется относительные URL, которые не имеют секций протокола и ЭВМ. Относительный URL может содержать компоненты относительного прохода к ресурсу (“..” означает положение порождающего URL). Документ RFC-1808 определяет алгоритм работы с относительными URL. Относительный URL может быть частью полного URL. Полный URL можно определить следующим образом:
Если базовый URL завершается символом (/), то он получен путем добавления относительного URL. Например, если базовый URL http://nosite.com/dir1/dir2/, а относительный – gee.html, то полный URL будет выглядеть как http://nosite.com/dir1/dir2/gee.html.
Если базовый URL не завершается /, последнюю секцию базового URL следует рассматривать как ресурс.
Для связи через электронную почту иногда используется специальная разновидность URL – mailto, которая имеет формат:
mailto:e-mail_адрес.
В HTML, URI используются для:
Связи с другим документом или ресурсом (см. элементы a и link).
Связи с внешним стилевым списком или скриптом (см. элементы link и script ).
Включения изображений объектов или аплетов в страницу (см. элементы img, object, applet и input).
Создания карты изображения (см. элементы map и area).
Предоставления форм (см. form).
Создания рамочных документов (см. элементы frame и iframe).
Цитирования внешних ссылок (см. элементы q, blockquote, ins и del).
Ссылок на соглашения по метаданным, описывающим документ (см. элемент head).
Поскольку люди на Земле пока используют различные языки, в которых применяются совершенно не схожие наборы символов, необходимо как-то управлять процессом описания набора символов, используемого в данном документе. Для документов HTML используется универсальный набор символов UCS (Universal Character Set) [ISO10646; cм. также RFC-2070]. Этот набор эквивалентен Unicode 2.0 [unicode]. Агент пользователя может получить, послать или воспроизвести документ в любой кодировке. Это может быть набор ISO-8859-1 (“latin-1”), ISO-8859-5 (кирилица), shift_jis (японская кодировка) и так далее.
Пользователь должен позаботиться, чтобы его документ в конечном итоге был приведен в соответствие с Unicode, тогда у него не будет более проблем с национальным шрифтовым набором.
Для того чтобы облегчить представление полученного документа, можно проанализировать первые несколько байт документа и в процессе пересылки соответствующим образом задать параметр charset поля “content-type”. Например:
content-type: text/html; charset= euc-jp
В качестве значения параметра charset может быть выбрано стандартное имя из документа [RFC-2045]. Но, к сожалению, отнюдь не все сервера присылают информацию об используемом символьном наборе даже в случае несовпадения с ISO-8859-1. Другим способом решить проблему является включение в заголовок документа соответствующего meta-элемента. Например:
<meta http-equiv=”content-type” content=”text/html; charset=euc-jp”>
Здесь крайне важно, чтобы агент пользователя был способен правильно интерпретировать элемент meta-декларации. Если других указаний не распознано, считается, что использован набор ISO-8859-1.
Значение типа атрибута “color” служит для описания цвета. Значение этого атрибута может быть шестнадцатеричным числом, перед которым записывается символ #, или одним из 16 имен цветов:
| black=”#000000” | white=”#ffffff” |
| silver=”#c0c0c0 | gray=”#808080” |
| green=”#008000” | lime=”#00ff00” |
| olive=”#808000” | maroon=”#800000” |
| yellow=”#ffff00” | aqua=”#00ffff” |
| red=”#ff0000” | blue=”#0000ff” |
| purple=”#800080” | teal=”#008080” |
| fuchsia=”#ff00ff” | navy=”#000080” |
HTML-документ состоит из трех частей, строки с информацией о версии, секции заголовка и собственно содержания документа. В первой строке документа должна быть внесена конструкция doctype, описывающая использованную версию HTML. Например:
<!doctype html public “-//w3c//dtd html 4.0 draft//en”>
Последние две буквы этой декларации характеризуют язык HTML dtd, в данном случае английский (“en”). Агент пользователя может игнорировать эту информацию. Слово draft говорит о том, что использована предварительная версия HTML 4.0. В случае работы с окончательной версией html 4.0 это слово должно быть заменено на strict. Часть документа, следующая после описания версии, должна быть оформлена в виде HTML-элемента. Таким образом, HTML-документ имеет следующую структуру:
<!doctype html public -//w3c//dtd html 4.0 draft//en>
<html>
Заголовок, текст документа …
</html>
Рассмотрим возможные варианты HTML-элементов.
<!entity % version “version cdata #fixed ‘%html.version;’”>
<!entity % html.content “head, (fragment|body) “>
<!entity html o o (%html.content)>
<!attlist html %version; %i18n; >
Стартовая и конечная метки являются опционными.
Ниже приведены примеры элементов-заголовков.
<!entity % head.content “title & isindex? & base?”>
<!element head o o (%head.content) +(%head.misc)>
<!attlist head %i18n; profile %url #implied – named directory of meta info -- >
Для элемента title стартовая и конечная метки являются обязательными. Элемент head содержит информацию о документе, он не является частью текста и служит в качестве источника ключевых слов для поисковых систем. HTML-документ должен иметь только один элемент title в секции head.
Не следует путать элемент title с атрибутом title, который предоставляет справочную информацию об элементе, для которого установлен. Атрибут title имеет формат: title=cdata. В отличие от элемента title, который характеризует весь документ в целом и может появиться в пределах документа только раз, атрибуту title позволено аннотировать любое число элементов. Агент пользователя может интерпретировать этот атрибут самым различным способом. Визуальные броузеры могут отобразить его текст в качестве совета, аудио агент может воспроизвести текст, говорящий о ресурсах подключенного сервера.
Специфическую роль играет атрибут title при использовании для элемента link.
В html 4.0 программист может использовать метаданные в своем документе следующим способом:
Можно описать свойства метаданных во внешнем профайле. Профайл может определить свойства вспомогательной системы поиска (help), такой как “автор”, “ключевые слова” и т.д..
Программист может установить значения определенных параметров. Это можно сделать внутри документа с помощью meta-элемента. В этом случае профайл определяет имена свойств, которые могут быть заданы с помощью META-элемента. Установить конкретные значения можно и извне, связав метаданные с элементом link. В этом варианте профайл определяет имена соотношений типов, которые может использовать элемент LINK.
Если профайл определен для элемента Head, тот же профайл будет присутствовать во всех элементах META и LINK в заголовке документа. Ниже приведены примеры записи элементов meta.
| <!element meta – o empty | -- Базовая метаинформация --> |
| <!attlist meta %i18n; | -- lang, dir, для использования со строкой содержимого -- |
| http-equiv name #implied | -- имя заголовка http-отклика -- |
| name name #implied | -- Имя метаинформации -- |
| content cdata #required | -- соответствующая информация -- |
| scheme sdata #implied | -- select form of content --> |
| name=Cdata | Этот атрибут определяет имя свойства. |
| content=Cdata | определяет значение свойства. |
| scheme=Cdata | определяет схему интерпретации значения свойства. |
| HTTP-equiv=cdata | может использоваться вместо атрибута name. http-серверы используют этот атрибут при сборе информации для заголовков откликов. |
Например:
<meta name=”interpreter” lang=”ru” content=”semenov”>.
Некоторые агенты пользователья используют meta для обновления текущей страницы каждые несколько секунд. При этом страница может обновляться полностью. Например:
<meta name=”refresh” content=”3,http://www.acme.com/intro.html”>
Слово content определяет задержку в секундах, за этим числом следует URL, который должен быть загружен по истечении указанного времени. К сожалению не все агенты пользователя поддерживают такую возможность.
Атрибут HTTP-equiv может использоваться вместо атрибута name. HTTP-серверы могут работать с именами свойств, заданными атрибутом HTTP-equiv, что позволяет им формировать заголовок HTTP-отклика согласно требованиям RFC-822. Декларация <meta http-equiv=”expires” content=”Mon, 17 Aug 1998 16:35:08 GMT”> приведет к формированию следующей строки в HTTP-заголовке: expires: Mon, 17 Aug 1998 16:35:08 GMT. Это позволяет определить время доступности свежей копии документа.
Одним из важных функция элемента meta является описание ключевых слов для поисковых систем. Например:
<meta name=”keywords” content=”information, retrieval, indexing”>
4. Элементы, используемые в тексте документа
<!entity % block “(%blocklevel | %inline)*”>
<!entity % color “cdata” – a color using srgb: #rrggbb as hex values -->
| <!entity % bodycolors “bgcolor | %color #implied | |
| text | %color #implied | |
| link | %color #implied | |
| vlink | %color #implied | |
| alink | %color #implied”> |
<!attlist body
| %attrs; | -- %coreattrs, %i18n, %events – | |
| background %url #implied | -- раскладка текстуры для фона документа -- | |
| %bodycolors; | -- bgcolor, text, link, vlink, alink – | |
| onload %script #implied | -- документ загружен -- | |
| onunload $script #implied | -- документ удален --> |
| Background=URL | указывает на место, где лежит изображение мозаичного образа для фона документа. |
| text=color | устанавливает фоновый цвет для текста. |
| Link=color | определяет цвет не посещенных гипертекстных объектов. |
| vlink=color | определяет цвет посещенных гипертекстных объектов. |
| alink=color | определяет цвет выбранного пользователем объекта. |
id, class, (идентификаторы действуют для всего документа) lang (языковая информация), dir (направление текста/отступ), title, style (текущая стилевая информация), bgcolor (цвет фона), onload, onunload, onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (действительные события).
Презентация документа определяется стилем (использование атрибутов презентации не желательно). Атрибуты презентации могут применяться только для агентов пользователя, не поддерживающих стили. Ниже представлена иллюстрация представления документа, где фон имеет белый цвет, текст черный, гиперсвязи в исходный момент красные, темные при активации и темно бордовые после первого визита.
<html>
<head>
| <title> a study of population dynamics </title> |
<body bgcolor=”white” text=”black” link=”red” alink=”fuschia” vlink=”maroon”>
… текст документа …
</body>
</html>
То же самое с использованием стилевого листа.
<html>
<head>
| <title> a study of population dynamics </title> |
| body { background: white color: black} | |
| a:link { color: red } | |
| a:visited { color: fuschia } |
</head>
<body>
| …текст документа … |
</html>
Использование связанного стилевого листа добавляет гибкости при реализации презентации.
<html>
<head>
| <title> a study of population dynamics </title> |
</head>
<body>
| …текст документа… |
</html>
5. Идентификаторы элементов. ID и атрибуты классов.
Определения атрибутов
ID = name
Этот атрибут присваивает имя элементу, которое действительно в пределах данного документа. Значение ID должно быть уникальным для данного документа.
class = cdata-list
Этот атрибут присваивает некоторому элементу значение класса или набора классов. Одно и тоже имя класса может быть присвоено любому числу элементов. Значение класса позволяет определить или уточнить функцию данного элемента или группы элементов.
Эти атрибуты могут использоваться в следующих случаях:
Атрибут id может использоваться в качестве адреса места назначения гипертекстной связи.
Атрибут id может использоваться скриптами для ссылки на какой-то конкретный элемент.
Стилевые листы могут использовать атрибут ID для того, чтобы определить элемент, на который распространяется действие данного стиля.
Атрибут ID может использоваться для идентификации деклараций object.
Стилевые листы могут использовать атрибут class для идентификации списка элементов, на которые распространяется действие данного стиля.
Атрибуты id и class могут использоваться для целей обработки, например, для идентификации полей при извлечении информации с HTML-страниц в базу данных, при трансляции HTML-документов в другие форматы.
Предположим, что пишется документ о языке программирования. Документ включает в себя некоторое число отформатированных примеров. В этом случае для форматирования используется элемент pre. Пусть также задан цвет фона = green для всех случаев, когда элемент pre принадлежит классу “example”.
<head>
<style pre.example { background : green } </style>
</head>
<body>
<pre class = “example” id = “example-1”>
… текст программы примера …
</pre>
</body>
5.1. Элемент html
<!entity % html.content "head, body">
| <!element html o o (%html.content;) | -- корневой элемент документа --> |
| <!attlist html %i18n; | -- lang, dir -- > |
/p> Определение атрибута
version = cdata [cn]
Применять не рекомендуется. Значение атрибута специфицирует то, какая версия HTML DTD используется в данном документе. Этот атрибут не рекомендован из-за того, что в качестве стандарта принято определение версии в декларации типа документа.
После декларации типа документа оставшаяся часть документа содержит элемент HTML. Таким образом, HTML-документ имеет структуру:
<!doctype html public "-//w3c//dtd html 4.0//en"
"http://www.w3.org/tr/rec-html40/strict.dtd">
<html>
...Заголовок, тело, и т.д. следует здесь...
</html>
5.2. Группирующие элементы div и span
<!element div - - %block>
| <!attlist div %attrs; | -- %coreattrs, %i18n, %events -- | |
| %align; | -- align, выравнивание текста -- > | |
| <!element span - - (%inline) * | -- базовый языковый/стилевой контейнер -- > | |
| <!element span %attrs; | -- %coreattrs, %i18n, %events -- > |
id, class (идентификаторы, действующие в пределах документа)
lang (языковая информация), dir (направление текста/отступ)
title (заголовок элемента)
style (текущая стилевая информация)
align (выравнивание)
onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (события)
Элементы div и span в сочетании с атрибутами id и class предлагают обобщенный механизм структурирования документа. Таким образом, сформировав примеры и классы и используя для них стилевые листы, программист может придать HTML-документу необходимую структуру и форму.
Предположим нужно сформировать документ на основе базы данных клиента. Так как HTML не имеет элементов, идентифицирующих такие объекты как “клиент”, “телефонный номер” и т.д., для решения стоящей задачи воспользуемся элементами div и span.
В приведенном примере каждое имя клиента принадлежит классу client-last-name. Присвоим также уникальные идентификаторы каждому клиенту (client-stepanov, client-ivanov).
<div id=”client-stepanov” class=”client”>
<span class=”client-last-name”>last name:</span> stepanov,
<span class=”client-first-name”>first name:</span> stepa
<span class=”client-tel”>telephone:</span> (095) 123-9442
<span class=”client-email”>email:</span> s.s@itep.ru">s.s@itep.ru
</div>
<div id=”client-ivanov” class=”client”>
<span class=”client-last-name”>last name:</span> ivanov,
<span class=”client-first-name”>first name:</span> vanja
<span class=”client-tel”>telephone:</span> (095) 123-5442
<span class=”client-email”>email:</span> s.s@itep.ru">v.i@itep.ru
</div>
Позднее может быть легко добавлена стилевая информация для тонкой настройки представления записей этой базы данных.
span является строчным элементом и его зона ответственности – параграф. span не может быть использован для группирования элементов блочного уровня. div, напротив, предназначен для работы с блочными элементами. div элемент, за которым следует незакрытый p-элемент, завершает параграф. Агент пользователя помещает разрыв строки до и после div-элемента, например строка:
<p>aaaaaa<div>bbbbbb</div><div>ccccc<p>ccccc</div>
обычно развертывается в:
aaaaaa
bbbbbb
ccccc
ccccc
Агент пользователя развернет ее как:
aaaaaabbbbbbccccc
ccccc
5.3. Элементы заголовков h1, h2, h3, h4, h5, h6
<!entity % heading “h1, h2, h3, h4, h5, h6”>
<!-- Существует шесть уровней заголовков, начиная с Н1 (наиважнейший), кончая Н6 -- >
<!element (%heading) - - (%inline;)*>
| <!attlist (%heading) %attrs; | -- %coreattrs, %i18n, %events -- | |
| %align; | -- align, выравнивание текста -- > |
Визуальные броузеры отображают заголовки более высокого уровня буквами более крупного кегля.
Ниже приведен пример использования div- элемента для установления связи заголовка со следующей за ним секцией документа. Это позволяет определить стиль раздела с помощью стилевых листов.
<div class=”section” id=”forest-elephants” >
<h1>forest elephants </h1>
В этом разделе обсуждаются менее известные лесные слоны.
… далее следует продолжение текста …
<div class=”subsection” id=”forest-habitant” >
<h2> habitant </h2>
Лесные слоны живут не на деревьях (:-))
… далее следует рассказ о том, где и как живут лесные слоны …
</div>
</div>
Структура может быть улучшена с помощью стилевой информации, например:
<head>
<style>
div.section { text-align: justify; font-size: 12pt }
div.subsection { text-ident: 2em }
h1 {font-style: italic; color: green }
h2 { color: green }
</style>
</head>
5.4. Элементы address
<!element address - - ((%inline;) | p) *>
| <!attlist address %attrs; | -- %coreattrs, %i18n, %events -- > |
<address>
newsletter editor<br>
j. r. brown<br>
8723 buena vista, smallville, ct 01234<br>
tel: +1 (123) 456 7890
</address>
6. Спецификация языка содержимого документа. Атрибут lang
lang = language-code
Специфицирует базовый язык, на котором написан документ. Значением этого атрибута является код языка (см. RFC-1766). В пределах кода языка пробелы использоваться не должны. Значение этого кода по умолчанию “unknown”. Код языка состоит из базового кода и субкода.
language-code = primary-code *( “-“ subcode )
Атрибуты, определенные где-либо еще.
id, class (идентификаторы, действующие в пределах документа)
lang (языковая информация), dir (направление текста/отступ)
onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (события)
Ниже приведено несколько примеров кодов языка.
“en”:english
“en-us”:the u.s version of english
| “en-cockney”:the cockney version of english | (версия английского – кокни) |
| “i-cherokee”: the cherokee language spoken by some native americans | (Чероки – язык, на котором говорят некоторые коренные американцы) |
| fr | французский |
| de | немецкий |
| it | итальянский |
| nl | голландский |
| el | греческий |
| es | испанский |
| pt | португальский |
| ar | арабский |
| he | еврейский |
| ru | русский |
| zh | китайский |
| ja | японский |
| hi | хинди |
| ur | урду |
7. Наследование языковых кодов
Элемент наследует информацию языкового кода согласно следующим приоритетам (сверху вниз):
Атрибут lang устанавливает значение элемента.
Глобальный элемент, имеющий атрибут lang.
http заголовок “content-language”, устанавливающий значения языка, например,
content-language: en-us.
Задание языкового атрибута извне.
В ниже приведенном примере базовый язык документа является французским. Один параграф декларирован как испанский, после чего базовый язык восстанавливается. Следующий параграф включает встроенную фразу на японском, после чего следует снова текст на французском.
<html lang=”fr”>
<body>
… текст интерпретируется как французский …
<p lang=”es”>… текст интерпретируется как испанский …
<p>… текст интерпретируется снова как французский …
<p> … французский текст интерпретируется с помощью <em lang=”ja”> немного японского </em> далее следует снова текст на французском …
</body>
</html>
8. Спецификация направления текста. Атрибут dir
Описание атрибута
dir = ltr | rtl
Специфицирует направление размещения текста, возможные значения:
ltr: слева направо
rtl: справа налево.
Последнее значение атрибута может быть нужно для случая арабского или еврейского текстов. Агент пользователя не может использовать атрибут lang для определения направления текста.
9. Текст
Пробел
Спецификация SGML делает различие между начальным символом (перевод строки) и концом записи (возврат каретки). Но существует большое разнообразие использования этих символов в различных системах и агент пользователя должен быть способен корректно обрабатывать все варианты. Аналогично меняется от скрипта к скрипту представление о том, что такое разделитель слов. В латинских текстах это пробел (десятичный код 32), в японском и китайском пробел игнорируется, а в тайском используется нуль-сепаратор. Что же касается самого HTML, здесь функции сепаратора выполняет код пробела. Набор символов документа включает в себя широкое разнообразие символов пробела. Многие из них являются типографскими элементами, которые служат для формирования зазоров между словами или буквами. В HTML, определены только следующие символы пробела:
ascii пробел ( )
ascii tab (	)
ascii form feed ()
пробел нулевой ширины (​)
Разрыв строки также является пробелом. Заметьте, что 
 и 
 определенные в [ISO10646] для разделения строк и параграфов, соответственно, не являются разрывами строк в HTML.
Пример текста:
<p>
this example shows a paragraph and a list
</p>
<ul>
| <li> |
</li>
| <li> |
</li>
</ul>
текст может быть переписан с пропуском конечных меток и размещен иначе с использованием меньшего числа пробелов.
<p>this example shows a paragraph and a list
<ul>
| <li> this is <em>первый</em> item | |
| <li> this is <em>второй</em> item |
Элемент pre используется для уже сформатированных фрагментов текста, где важны пробелы.
9.1. Структурированный текст
Элементы фраз: em, strong, dfn, code, samp, kbd, var, cite, acronym
<!entity % phrase “em | strong | dfn | code | samp | kbd | var | citr | acronym”>
<!element (%font|%phrase) - - (%inline) *>
| <!attlist (%font|%phrase) | -- %coreattrs, %i18n, %events -- > |
em: |
Подчеркивают значение. |
| strong: | Указывает на еще большую важность (придает выразительность) |
| dfn: | Указывает, что это место определения вложенного термина. |
| code: | Отмечает фрагмент текста программы. |
| samp: | Выделяет пример из текста программы или скрипта. |
| kbd: | Отмечает текст, который должен быть введен пользователем. |
| var: | Отмечает переменную или аргумент программы |
| cite: | Ссылается на фрагмент текста или другой источник. |
| acronym: | Отмечает акроним (напр. HTML, URI, WWW и т.д.). |
“More information can be found in <cite>[ISO-0000]</cite>
“Please refer to the following reference number in future correspondence:
<strong>1-234-55</strong>”
Элемент acronym позволяет упростить работу программ проверки правописания и звуковых синтезаторов речи. Текст элемента acronym позволяет описать сам акроним:
<acronym title=”world wide web”>www</acronym>
<acronym lang=”fr” title =”société nationale de chemins de fer”> sncf
</acronym>
Представление элементов фраз зависит от агента пользователя. Визуальные броузеры отмечают фрагменты текста EM курсивом, а фрагменты strong - полужирным шрифтом. HTML не выделяет аббревиатур и акронимов, по этой причине в текстах, ориентированных на звуковое воспроизведение, следует позаботиться о создании специальных словарей, подключенных к тексту с помощью элементов link в заголовке документа.
9.2. Цитирование. Элементы q и blockquote
<!element blockquote - - %block>
| <!attlist blockquote %attrs; | -- %coreattrs, %i18n, %events -- | |
| cite %url #implied | -- url исходного документа или сообщения -- > | |
/p> <!element q - - (%inline) *>
| <!attlist q %attrs; | -- %coreattrs, %i18n, %events -- | |
| cite %url #implied | -- url исходного документа или сообщения -- > |
cite=url
Значение этого атрибута равно url, который указывает на первоисточник или сообщение. Аргумент указывает на источник цитаты, заключенной в кавычки. Элемент q служит для использования с короткими цитатами в пределах абзаца, а blockquote предназначен для более длинных. Например:
<blockquote cite=http://www.mycom.com/tolkien/twotpwers.html>
they went in single file, running like hounds on a strong scent, and an eager light was in their eyes.
</blockquote>
9.3. Верхние и нижние индексы. Элементы sub и sup
<!element (sub|sup) - - (%inline) *>
| <!attlist (sub|sup) %attrs; | -- %coreattrs, %i18n, %events --> |
m<sup>lle</sup> dupont
9.4. Строки и параграфы
Любой текст обычно представляется в виде последовательности параграфов. Для определения границ параграфа в HTML используется элемент p. Текст параграфа будет использоваться как единое целое при ряде процедур.
9.4.1. Параграфы и элемент p
<! element p – o (%inline) *>
| <!attlist p %attrs; | -- %coreattrs, %i18n, %events | |
| %align; | -- выравнивание текста -- > |
<p>Это первый параграф.</p>
<p>Это второй </p>
… блочный элемент …
Этот же текст можно переписать эквивалентным образом:
<p>Это первый параграф.
<p>Это второй.
…блочный элемент …
Аналогично параграф может быть сформирован с помощью блочных элементов:
<div>
<p> Это параграф
</div>
Пустой параграф является дурным стилем и должен игнорироваться агентом пользователя.
Агент пользователя определяет способ отображения параграфа. Параграфы могут иметь абзацы, а могут отделяться друг от друга пустой строкой. Обычно в процессе отображения строки разрываются по пробелам между словами, но можно ввести принудительные разрывы строк с помощью элемента BR.
9.5. Элемент br
<!element br – o empty |
-- вызывает разрыв строки -- > | |
| <!attlist br %coreattrs; | -- id, class, style, title -- | |
| clear (left|all|right|none) none | -- управление отображением текста -- > |
Помимо принудительного разрыва строки существует элемент, запрещающий разрыв строки между двумя словами. Например entity ( ,  ) действует как пробел, где агент пользователя не должен разрывать строку.
В HTML существует два вида дефисов: мягкий и твердый. Твердый рассматривается как обычный символ, а мягкий воспринимается агентом пользователя как место, где можно разорвать строку. Твердый дефис обозначается символом “-“ (-,-), а мягкий – именованным символом ­ (­,­).
9.6. Предварительно сформатированный текст. Элемент pre.
<!entity % pre.exclusion “img|big|small|sub|sup|font”>
<!element pre - - (%inline) * - (%pre.exclusion)>
| <!attlist pre %attrs; | -- %coreattrs, %i18n, %events -- |
| width number #implied > |
width = integer
Этот атрибут дает информацию агенту пользователя о желательной ширине форматируемого блока. Агент пользователя может использовать эту информацию для выбора шрифта или отступа. Желательная ширина выражается в числе символов.
Элемент pre сообщает визуальному агенту пользователя, что данный фрагмент текста уже сформатирован. Агент пользователя при этом должен сохранить все пробелы, использовать шрифт с фиксированной шириной букв, блокировать автоматический перенос и разрыв строк.
Перед и после такого фрагмента обычно вводятся пустые строки (требование SGML). В DTD-фрагменте, приведенном выше, в первой строке содержится список элементов, которые не должны присутствовать в PRE-декларации. Рассмотрим фрагмент из поэмы Шелли “to a skylark”.
<pre>
| higher still and higher | ||
| from the earth thou springest | ||
| like a cloud of fire; | ||
| the blue deep thou wingest, |
</pre>
Этот стих будет представлен агентом пользователя без изменений формата.
Не рекомендуется использовать горизонтальную табуляцию в предварительно отформатированных текстах, агент пользователя не сможет воспроизвести формат фрагмента без искажений.
10. Пометка изменений документа. Элементы ins и del.
<!element (ins|del) - - (%inline) * |
-- (введенный/удаленный текст) -- > | |
| <!attlist (ins|del) %attrs; | -- %coreattrs, %i18n, %events -- | |
| cite %url #implied | -- информация о причине изменения -- | |
| datetime cdata #implied | -- дата изменения в формате ISO -- > |
cite = URL
Значение этого атрибута равно URL, которое указывает на документ-первоисточник. Атрибут служит для пояснения причины изменения документа.
datetime = cdata
Значение этого атрибута определяет дату и время внесения изменения в документ. Формат этого значения должен соответствовать требованиям документа ISO-8601.
Элементы ins и del используются для выделения фрагментов документа, которые были добавлены или удалены из предшествующей версии документа.
11. Формат даты и времени
ISO-8601 допускает много опций и вариаций в представлении дат и времени. Но основным форматом HTML следует считать следующий:
yyyy-mm-ddthh:mm:sstzd
| Где | yyyy | = четыре цифры года |
| mm | = две цифры месяца (01 – январь) | |
| dd | = две цифры дня месяца (01-31) | |
| hh | = две цифры часа (00-23; am/pm запрещены) | |
| mm | = две цифры минут (00-59) | |
| ss | = две цифры секунд (00-59) | |
| tzd | = идентификатор временной зоны |
/p> В качестве tzd ( код временной зоны) можно использовать следующие:
| z | обозначает utc (coordinated universal time) |
| +hh:mm | указывает местное время в часах и минутах опережающее utc. |
| -hh:mm | указывает местное время в часах и минутах отстающее от utc. |
12. Неупорядоченные (ul) и упорядоченные (ol) списки
<!entity % ulstyle “disc|square|circle”>
<!element ul - - (li) +>
| <!attlist ul | -- неупорядоченный список -- | |
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| type (%ulstyle) #implied | -- список, где элементы отмечены жирной точкой в начале строки -- | |
| compact (compact) #implied | -- уменьшенное расстояние между элементами списка -- > | |
| <!entity % olstyle “cdata” | -- определяет стиль нумерации: [1|a|a|i|i] -- > | |
| <!element ol - - (li) +> | ||
| <!attlist ol | -- упорядоченный список -- | |
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| type (%olstyle) #implied | -- нумерованный список -- | |
| compact (compact) #implied | -- уменьшенное расстояние между элементами списка -- | |
| start number #implied | -- начальный номер элемента списка -- > | |
| <!entity % listyle “cdata” | -- ограничение: “(%ulstyle|%olstyle)” -- > | |
| <!element li - o %block | -- элемент списка -- > | |
| <!attlist li %attrs; | -- %coreattrs, %i18n, %events -- | |
| type %listyle) #implied | -- стиль элемента списка -- | |
| value number #implied | -- сброс счетчика элементов списка -- > |
type = style-information
Этот атрибут определяет стиль элемента списка.
start = integer
Работает только для ol. Устанавливает начальное значение счетчика элементов упорядоченного списка, значение по умолчанию равно единице.
value = integer
Работает только для LI. Устанавливает текущее значение номера элемента списка.
compact
Не рекомендуется использовать. При использовании требует от агента пользователя отображать список в возможно более компактном виде.
Упорядоченные и не упорядоченные списки во многом схожи.
Оба типа представляют собой последовательность элементов, описанных элементом LI (конечная метка этого элемента обычно опускается). Ниже приведены примеры списков.
<ul>
| <li> … первый элемент списка … | |
| <li> … второй элемент списка … | |
| …………. |
Списки могут быть вложенными.
<ul>
| <li> …Уровень 1, номер 1 … | |||
| <ol> | |||
| <li> … Уровень 2, номер 1 … | |||
| <li> … Уровень 2, номер 2 … | |||
| <ol start=”10”> | |||
| <li> … Уровень 3, номер 1 … | |||
| </ol> | |||
| <li> … Уровень 2, номер 3 … | |||
| </ol> | |||
| <li> …Уровень 1, номер 2 … |
В упорядоченных списках невозможно продолжать нумерацию с предыдущего списка или убрать нумерацию, но можно установить счетчик принудительно с помощью атрибута value. Например:
<ol>
<li value=”30”> присваивает этому элементу списка номер 30.
<li value=”40”> присваивает этому элементу списка номер 40.
<li> этот элемент списка будет иметь номер 41.
</ol>
12.1. Списки, форматируемые визуальным агентом пользователя
Для OL и UL атрибут type определяет опцию отображения визуальным агентом пользователя. Для элемента UL возможны значения атрибута type: disc, square и circle. Значение по умолчанию зависит от уровня вложения текущего списка. Агент пользователя попытается представить “disc” в виде небольшого заполненного кружочка, “circle” – в виде незаполненного кружочка, а “square” – в виде квадратика.
Для элемента ol возможные значения атрибута type представлены в таблице.
| Тип | Стиль нумерации | |
| 1 | Арабские цифры | 1,2,3,… |
| a | Строчные буквы латинского алфавита | a,b,c,… |
| a | Прописные буквы латинского алфавита | a,b,c, … |
| i | Малые римские цифры | i, ii, iii, … |
| i | Большие римские цифры | i, ii, iii, … |
<!element dl - - (dt|dd)+>
| <!attlist dl %attrs | -- %coreattrs, %i18n, %events -- | |
| compact (compact) #implied | -- уменьшенное расстояние между элементами -- > |
/p> <!element dt – o (%inline) *>
<!element dd – o %block>
| <!attlist (dt|dd) %attrs | -- %coreattrs, %i18n, %events -- > |
<dl>
| <dt> <em> daniel</em> | ||
| <dd> born in france, daniel’s favorite food is foie gras. | ||
| <p> in this paragraph we’ll discuss daniel’s girlfriends: audrey, laurie and alice. |
| <dt> <em> tim</em> | |
| <dd> born in new york, tim’s favorite food is ice cream. |
Представление списка определений зависит от агента пользователя. Агент пользователя может отобразить представленный список в виде:
daniel
born in france, daniel’s favorite food is foie gras.
in this paragraph we’ll discuss daniel’s girlfriends: audrey, laurie and alice.
tim
born in new york, tim’s favorite food is ice cream.
13. dir и элементы menu
<!element (dir|menu) - - (li)+ - (%blocklevel)>
| <!attlist dir %attrs; | -- %coreattrs, %i18n, %events -- |
| compact (compact) #implied > | |
| <!attlist menu %attrs; | -- %coreattrs, %i18n, %events -- |
| compact (compact) #implied > |
14. Таблицы
Модель таблиц в HTML позволяет пользователям создавать достаточно сложные структуры таблиц. В этой модели ряды и колонки можно объединять в группы. При печати больших таблиц заголовки и нижние комментарии могут дублироваться для каждой части.
14.1. Структура таблиц
В HTML таблицы имеют следующую структуру
Допускается одна или более групп строк. Каждая группа состоит из опционной секции заголовка таблицы и опционной нижней секции.
Допускается одна или более групп колонок.
Каждая строка состоит из одной или более ячеек.
Каждая ячейка может содержать заголовок или информацию и занимать более одной строки и более одной колонки.
14.1.1. Элемент table
<!element table - - (caption?, (col*|colgroup*), thead?, tfoot?, tbody+)>
<!attlist table -- элемент таблицы –
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| align %talign; #implied | -- положение таблицы относительно окна -- | |
| bgcolor %color #implied | -- фоновый цвет ячейки -- | |
| width cdata #implied | -- ширина таблицы относительно окна -- | |
| cols number #implied | -- используется для режима немедленного отображения -- | |
| borrder cdata #implied | -- управляет шириной рамки вокруг таблицы -- | |
| frame %tframe; #implied | -- какую часть таблицы заключить в рамку -- | |
| rules %trules #implied | -- линии между рядами и колонками -- | |
| cellspacing cdata #implied | -- зазоры между ячейками -- | |
| cellpadding cdata #iplied | -- отступы внутри ячеек -- > |
align = left | center | right
Этот атрибут определяет положение таблицы в документе. Возможные значения:
left:
Определения полей заголовка
4.5.6.1.13. Определения полей заголовка
Этот раздел определяет синтаксис и семантику всех стандартных полей заголовков HTTP/1.1. Для полей заголовков объекта, как отправитель, так и получатель могут рассматриваться клиентом или сервером в зависимости от того, кто получает объект.
Поле заголовка запроса Accept может использоваться для спецификации определенных типов среды, которые приемлемы для данного ресурса. Заголовки Accept могут использоваться для индикации того, что запрос ограничен в рамках определенного набора типов, как в случае запросов отображения в текущей строке.
| Accept | = "Accept" ":" |
| #( media-range [ accept-params ] ) | |
| media-range | = ( "*/*" |
| | ( type "/" "*") | |
| | ( type "/" subtype ) | |
| ) *( ";" parameter ) |
accept-params = ";" "q" "=" qvalue *( accept-extension )
accept-extension = ";" token [ "=" ( token | quoted-string ) ]
Символ звездочка "*" используется для того, чтобы группировать типы среды в группы с "*/*", указывающим на все типы, и "type/*", указывающим на все субтипы данного типа. Группа сред может включать в себя параметры типа среды, которые применимы. За каждой группой сред может следовать один или более параметров приема (accept-params), начинающихся с "q" параметра для указания фактора относительного качества. Первый "q" параметр (если таковой имеется) отделяет параметры группы сред от параметров приема. Факторы качества позволяют пользователю или агенту пользователя указать относительную степень предпочтения для данной группы сред, используя шкалу значений q от 0 до 1 (раздел 2.9). Значение по умолчанию соответствует q=1.
Замечание. Использование имени параметра "q" для разделения параметров типа среды от параметров расширения Accept связано с исторической практикой. Это мешает присвоения параметру типа среды имени "q".
Пример Accept: audio/*; q=0.2, audio/basic.
Должно интерпретироваться, как "Я предпочитаю audio/basic, но шлите мне любые типы аудио, если это лучшее, что имеется после 80% понижения качества". Если поле заголовка Accept отсутствует, тогда предполагается, что клиент воспринимает все типы среды. Если поле заголовка Accept присутствует и, если сервер не может послать отклик, который является приемлемым, согласно комбинированному значению поля Accept, тогда сервер должен послать отклик 406 (not acceptable). Более сложный пример.
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c
Это будет интерпретироваться следующим образом: "text/html и text/x-c являются предпочтительными типами сред, но, если их нет, тогда следует слать объект text/x-dvi, если он отсутствует, следует присылать объект типа text/plain".
Группы сред могут быть заменены другими группами или некоторыми специальными типами среды. Если используется более одного типа среды для данного типа, предпочтение отдается наиболее специфичному типу. Например,
Accept: text/*, text/html, text/html;level=1, */*
имеет следующие предпочтения:
1) text/html;level=1
2) text/html
3) text/*
4) */*
Фактор качества типа среды, ассоциированный с данным типом определен путем нахождения группы сред с наивысшим предпочтением, который подходит для данного типа. Например,
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
text/html;level=2;q=0.4, */*;q=0.5
в результате будут установлены следующие величины:
| text/html;level=1 | = 1 |
| text/html | = 0.7 |
| text/plain | = 0.3 |
| image/jpeg | = 0.5 |
| text/html;level=2 | = 0.4 |
| text/html;level=3 ; | = 0.7 |
13.2. Поле Accept-Charset
Поле заголовка запроса Accept- Charset может быть использовано для указания того, какой символьный набор приемлем для отклика. Это поле позволяет клиентам, способным распознавать более обширные или специальные наборы символов, сигнализировать об этой возможности серверу, который способен представлять документы в рамках этих символьных наборов. Набор символов ISO-8859-1 может считаться приемлемым для всех агентов пользователя.
Accept-Charset = "Accept-Charset" ":"
1#( charset [ ";" "q" "=" qvalue ] )
Значения символьных наборов описаны в разделе 2.4. Каждому символьному набору может быть поставлено в соответствие значение качества, которое характеризует степень предпочтения пользователя для данного набора. Значение по умолчанию q=1. Например Accept-Charset: ISO-8859-5, unicode-1-1;q=0.8. Если заголовок Accept-Charset отсутствует, по умолчанию это означает, что приемлем любой символьный набор. Если заголовок Accept-Charset присутствует, и, если сервер не может послать отклик, который приемлем с точки зрения заголовка Accept-Charset, тогда он должен послать сообщение об ошибке со статусным кодом 406 (not acceptable), хотя допускается посылка и отклика "unacceptable".
13.3. Поле Accept-Encoding
Поле заголовка запроса Accept-Encoding сходно с полем Accept, но регламентирует кодировку содержимого (раздел 13.12), которая приемлема в отклике.
Accept-Encoding = "Accept-Encoding" ":"
#( content-coding )
Ниже приведен пример его использования Accept-Encoding: compress, gzip
Если заголовок Accept-Encoding в запросе отсутствует, сервер может предполагать, что клиент воспримет любую кодировку информации. Если заголовок Accept-Encoding присутствует и, если сервер не может послать отклик, приемлемый согласно этому заголовку, тогда серверу следует послать сообщение об ошибке со статусным кодом 406 (Not Acceptable). Пустое поле Accept-Encoding указывает на то, что не приемлемо никакое кодирование.
13.4. Поле Accept-Language
Поле заголовка запроса Accept-Language сходно с полем Accept, но регламентирует набор естественных языков, которые предпочтительны в отклике на запрос.
| Accept-Language | = "Accept-Language" ":" |
| 1#( language-range [ ";" "q" "=" qvalue ] ) | |
| language-range | = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) |
Accept-Language: da, en-gb;q=0.8, en;q=0.7
будет означать: "Я предпочитаю датский, но восприму британский английский и другие типы английского". Список языков согласуется с языковой меткой, если он в точности равен метке или, если он в точности равен префиксу метки, такому как первый символ метки, за которым следует символ "-". Специальный список "*", если он присутствует в поле Accept-Language, согласуется с любой меткой.
Замечание. Это использование префикса не предполагает, что языковые метки присвоены языкам таким образом, что, если пользователь понимает язык с определенной меткой, то он поймет все языки, имеющие метки с одним и тем же префиксом. Правило префикса просто позволяет использовать префиксные метки для случаев, когда это справедливо.
Фактор качества, присваиваемый языковой метке с помощью поля Accept-Language, равен значению качества самого длинного списка языков в поле. Если в поле отсутствует список языков, фактору качества присваивается значение нуль. Если в запросе отсутствует заголовок Accept-Language, серверу следует предполагать, что все языки приемлемы в равной мере. Если заголовок Accept-Language имеется, тогда все языки, которым присвоен фактор качества больше нуля, приемлемы.
Посылка заголовка Accept-Language с полным списком языковых предпочтений пользователя в каждом запросе может восприниматься как нарушение принципов конфиденциальности.
Обсуждение этой проблемы смотри в разделе 14.7.
Замечание. Так как степень интеллигентности в высшей степени индивидуальна, рекомендуется, чтобы приложения клиента делали выбор языковых предпочтений доступным для пользователя. Если выбор не сделан доступным, тогда поле заголовка Accept-Language не должно присутствовать в запросе.
13.5. Поле Accept-Ranges
Поле заголовка отклика Accept-Ranges позволяет серверу указать доступность широкодиапазонных запросов к ресурсу:
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
acceptable-ranges = 1#range-unit | "none"
Исходные серверы, которые воспринимают байт-диапазонные запросы, могут послать
Accept-Ranges: bytes
но делать это необязательно. Клиенты могут выдавать байт-диапазонные запросы, не получив этот заголовок отклика для запрашиваемого ресурса. Серверы, которые не могут работать с какими-либо диапазонными запросами, могут послать
Accept-Ranges: none,
чтобы посоветовать клиенту, не пытаться посылать такие запросы.
13.6. Поле Age
Поле заголовка отклика Age передает оценку отправителем времени с момента формирования отклика исходным сервером (или перепроверки его пригодности). Кэшированный отклик является свежим, если его возраст не превышает его времени жизни. Значения Age вычисляются согласно рекомендациям представленным разделе 12.2.3.
| Age | = "Age" ":" age-value |
| age-value | = delta-seconds |
Если кэш получает величину больше, чем наибольшее положительное число, которое он может себе представить или, если вычисление возраста вызвало переполнение, он должен передать заголовок Age со значением 2147483648 (231). Кэши HTTP/1.1 должны
посылать заголовки Age в каждом отклике. Кэшам следует использовать арифметический тип чисел не менее 31 бита.
13.7. Поле Allow
Поле заголовка объекта Allow перечисляет набор методов, поддерживаемых ресурсом, идентифицированным Request-URI.
Целью этого поля является точное информирование получателя о рабочих методах данного ресурса. Поле заголовка Allow должно быть представлено в отклике 405 (Method Not Allowed).
Allow = "Allow" ":" 1#method
Пример использования:
Allow: GET, HEAD, PUT
Это поле не препятствует клиенту испытать другие методы. Однако указания, данные в значение поля заголовка Allow, следует выполнять. Действительный набор методов определяется исходным сервером во время каждого запроса.
Поле заголовка Allow может быть прислано запросом PUT, чтобы рекомендовать методы, которые будут поддерживаться новым или модифицированным ресурсом. Серверу не обязательно поддерживает эти методы, но ему следует включить заголовок Allow в отклик, чтобы сообщить действительно поддерживаемые методы.
Прокси не должен модифицировать поле заголовка Allow, даже если он не понимает все специфицированные методы, так как агент пользователя может иметь другие средства связи с исходным сервером.
Поле заголовка Allow не указывают на то, что методы реализованы на уровне сервера. Серверы могут использовать поле заголовка отклика Public (раздел 13.35), чтобы описать, какие методы реализованы на сервере.
13.8. Авторизация
Агент пользователя, который хочет авторизовать себя на сервере может сделать это после получения отклика 401, включив в запрос поле заголовка Authorization. Значение поля Authorization состоит из идентификационной информации агента пользователя для области (realm) запрошенных ресурсов.
Authorization = "Authorization" ":" credentials
Авторизация доступа HTTP описана в разделе 10. Если запрос идентифицирован и область специфицирована, та же самая идентификационная информация может быть использована для других запросов в пределах данной области.
Когда кэш коллективного пользования (см. раздел 12.7) получает запрос, содержащий поле Authorization, он не должен присылать соответствующий отклик в качестве ответа на какой-либо другой запрос, если только не выполняется одно из следующих условий:
Если отклик включает в себя директиву Cache-Control "proxy-revalidate", кэш может использовать этот отклик при последующих запросах, но прокси-кэш должен сначала перепроверить его пригодность с помощью исходного сервера, используя заголовки нового запроса для того, чтобы исходный сервер мог идентифицировать новый запрос.
Если отклик содержит в себе директиву Cache-Control "must-revalidate", кэш может использовать этот отклик при ответах на последующие запросы, но все кэши должны сначала перепроверить пригодность откликов с помощью исходного сервера, используя заголовки нового запроса для того, чтобы сервер мог идентифицировать новый запрос.
Если отклик содержит директиву Cache-Control "public", то этот отклик может быть отослан в ответ на любой последующий запрос.
13.9. Поле Cache-Control
Поле общего заголовка Cache-Control используется для спецификации директив, которые должны исполняться всеми механизмами кэширования вдоль цепочки запрос/отклик. Директивы определяют поведение, которое, как предполагается, должно предотвратить нежелательную интерференцию откликов или запросов в кэше. Эти директивы обычно переписывают алгоритм кэширования, используемый по умолчанию. Директивы кэша являются однонаправленными, присутствие директивы в запросе не предполагает, что та же директива будет присутствовать и в отклике.
Заметьте, что кэши HTTP/1.0 могут не реализовывать управление (Cache-Control), а могут использовать только директиву Pragma: no-cache (см. раздел 13.32).
Директивы кэша должны пропускаться через приложения прокси или внешнего шлюза (gateway), вне зависимости от их значения для этого приложения, так как директивы могут быть применимы для всех получателей в цепочке запрос/отклик. Невозможно специфицировать директивы для отдельных кэшей.
| Cache-Control | = "Cache-Control" ":" 1#cache-directive |
| cache-directive | = cache-request-directive |
| | cache-response-directive | |
| cache-request-directive | = "no-cash" ["=" 1#field-name] |
| | "no-store" | |
| | "max-age" "=" delta-seconds | |
| | "max-stale" [ "=" delta-seconds ] | |
| | "min-fresh" "=" delta-seconds | |
| | "only-if-cached" | |
| | cache-extension | |
| cache-response-directive | = "public" |
| | "private" [ "=" 1#field-name ] | |
| | "no-cache" [ "=" 1#field-name ] | |
| | "no-store" | |
| | "no-transform" | |
| | "must-revalidate" | |
| | "max-age" "=" delta-seconds | |
| | cache-extension; | |
| cache-extension | = token [ "=" ( token | quoted-string ) ] |
/p> Если директива появляется без какого-либо параметра 1#field-name, она воздействует на весь запрос или отклик. Когда такая директива приходит с параметром 1#field-name, она воздействует только на именованное поле или поля и не имеет никакого действия на остальную часть запроса или отклика. Этот механизм поддерживает расширяемость. Реализации будущих версий протокола HTTP могут использовать эти директивы для полей заголовка, неопределенных в HTTP/1.1.
Директивы управления кэшем могут быть разделены на следующие категории:
Ограничения на то, что можно кэшировать. Они налагаются только исходным сервером.
Ограничения на то, что можно записывать в память кэша. Они определяются исходным сервером или агентом пользователя.
Модификации базового механизма контроля годности записей. Они вносятся либо исходным сервером, либо агентом пользователя.
Управление процессом перепроверки годности записей и перезагрузкой осуществляется только агентом пользователя.
Управление преобразованием объектов.
Расширения системы кэширования.
13.9.1. Что допускает кэширование?
По умолчанию отклик допускает кэширование, если требования метода запроса, поля заголовка запроса и код статуса отклика указывают на то, что кэширование не запрещено. Раздел 12.4 обобщает эти рекомендации для кэширования. Следующие Cache-Control директивы отклика позволяют исходному серверу переписать стандартные требования по кэшируемости:
public
Указывает, что отклик может кэшироваться любым кэшем, даже если он в норме не кэшируем или кэшируем только в кэшах индивидуального пользования. (См. также об авторизации в разделе 13.8.)
private
Указывает, что весь или часть сообщения отклика предназначена для одного пользователя и не должна быть записана кэшем коллективного пользования. Это позволяет исходному серверу заявить о том, что специфицированные части отклика предназначены только для одного пользователя, и он не может отсылаться в ответ на запросы других пользователей. Частный кэш может кэшировать такие отклики.
Замечание. Это использование слова частный (private) определяет только возможность кэширования и не гарантирует конфиденциальности для содержимого сообщения.
no-cache
Указывает, весь или фрагмент сообщения-отклика не должны кэшироваться, где бы то ни было. Это позволяет исходному серверу предотвратить кэширование даже для кэшей, сконфигурированных для рассылки устаревших откликов.
Замечание. Большинство кэшей HTTP/1.0 не распознают и не исполняют эту директиву.
13.9.2. Что может быть записано в память кэша?
Целью директивы no-store (не запоминать) является предотвращение ненамеренного распространения или записи конфиденциальной информации (например, на backup ленты). Директива no-store применяется для всего сообщения и может быть послана как в отклике, так и в запросе. При посылке в запросе кэш не должен запоминать какую-либо часть этого запроса или присланного в ответ отклика. При посылке в отклике, кэш не должен запоминать какую-либо часть отклика или запроса, его вызвавшего. Эта директива действует как для индивидуальных кэшей, так и кэшей коллективного пользования. "Не должно запоминаться" в данном контексте означает, что кэш не должен заносить отклик в долговременную память и должен сделать все от него зависящее для того, чтобы удалить эту информацию из временной памяти после переадресации этих данных.
Даже когда эта директива ассоциирована с откликом, пользователи могут непосредственно запомнить такой отклик вне системы кэширования (например, с помощью диалога "Save As"). Буферы предыстории могут запоминать такие отклики как часть своей нормальной работы.
Цель этой директивы обеспечение выполнения определенных требований пользователей и разработчиков, кто связан с проблемами случайного раскрытия информации за счет непредвиденного доступа к структуре данных кэша. При использовании этой директивы можно в некоторых случаях улучшить конфиденциальность, но следует учитывать, что не существует какого-либо надежного механизма для обеспечения конфиденциальности.
В частности, некоторые кэши могут не распознавать или не выполнять эту директиву, а коммуникационные сети могут прослушиваться.
13.9.3. Модификации базового механизма контроля времени жизни
Время пригодности объекта (entity expiration time) может быть специфицировано исходным сервером с помощью заголовка Expires (см. раздел 13.21). Другой возможностью является применение директивы max-age в отклике.
Если отклик включает в себя как заголовок Expires, так и директиву max-age, более высокий приоритет имеет директива max-age, даже если заголовок Expires накладывает более жесткие ограничения. Это правило позволяет исходному серверу обеспечить для заданного отклика большее время жизни в случае объектов кэша HTTP/1.1 (или более поздней версии), чем в HTTP/1.0. Это может быть полезным, если кэш HTTP/1.0 некорректно вычисляет возраст объекта или его время пригодности, например, из-за не синхронности часов.
Замечание. Большинство старых кэшей, несовместимых с данной спецификацией, не поддерживают применение директив управления кэшем. Исходный сервер, желающий применить директиву управления кэшем, которая ограничивает, но не запрещает кэширование в системах, следующих регламентациям HTTP/1.1, может использовать то, что директива max-age переписывает значение, определенное Expires.
Другие директивы позволяют агенту пользователя модифицировать механизм контроля времени жизни объектов. Эти директивы могут быть специфицированы в запросе max-age.
Этот запрос указывает, что клиент желает воспринять отклик, чей возраст не больше времени, заданного в секундах. Если только не включена также директива max-stale, клиент не воспримет устаревший отклик.
Запрос min-fresh указывает, что клиент желает воспринять отклик, чье время жизни не меньше, чем его текущий возраст плюс заданное время в секундах. То есть, клиент хочет получит отклик, который будет еще свежим, по крайней мере, заданное число секунд.
Запрос max-stale указывает, что клиент желает воспринять отклик, время жизни которого истекло.
Если max- stale присвоено конкретное значение, тогда клиент хочет получить отклик, время жизни которого не ранее, чем заданное число секунд тому назад. Если значения max-stale в директиве не указано, тогда клиент готов воспринять отклики любого возраста.
Если кэш присылает устаревший отклик, из-за наличия в запросе директивы max-stale, либо потому, что кэш сконфигурирован таким образом, что переписывает время жизни откликов, кэш должен присоединить заголовок предупреждения к отклику, используя Warning 10 (Response is stale - отклик устарел).
13.9.4. Управление перепроверкой пригодности и перезагрузкой
Иногда агент пользователя может потребовать, чтобы кэш перепроверил пригодность своих записей с помощью исходного сервера (а не соседнего кэша по пути к исходному серверу), или перезагрузил свой кэш из исходного сервера. Может потребоваться перепроверка End-to-end, если и кэш и исходный сервер имеют завышенные оценки времени жизни кэшированных откликов. Перезагрузка End-to-end может потребоваться, если запись в кэше оказалась по какой-то причине поврежденной.
Перепроверка типа End-to-end может быть запрошена в случае, когда клиент не имеет своей локальной копии, этот вариант мы называем "не специфицированная перепроверка end-to-end", или когда клиент имеет локальную копию, такой вариант называется "специфической перепроверкой end-to-end."
Клиент может потребовать три вида действий, используя в запросе директивы управления кэшем:
End-to-end reload
Запрос включает в себя директиву управления кэшем "no-cache" или, для совместимости с клиентами HTTP/1.0, "Pragma: no-cache". В запросе с директивой no-cache может не быть никаких имен полей. Сервер не должен использовать кэшированную копию при ответе на этот запрос.
Specific end-to-end revalidation
Запрос включает в себя директиву управления кэшем "max-age=0", которая вынуждает каждый кэш вдоль пути к исходному серверу сверить свою собственную запись, если она имеются, с записью следующего кэша или сервера.
Исходный запрос включает в себя требования перепроверки для текущего значениея валидатора клиента.
Unspecified end-to-end revalidation
Запрос включает в себя директиву управления кэшем "max-age=0", которая вынуждает каждый кэш вдоль пути к исходному серверу сверить свою собственную запись, с записью следующего кэша или сервера. Исходный запрос не включает в себя требований перепроверки. Первый кэш по пути (если таковой имеется), который содержит запись данного ресурса, подключает условия перепроверки со своим текущим валидатором.
Когда промежуточный кэш вынуждается с помощью директивы max-age=0 перепроверить свои записи, присланный клиентом валидатор может отличаться от того, что записан в данный момент в кэше. В этом случае кэш может воспользоваться в своем запросе любой из валидаторов, не нарушая семантической прозрачности.
Однако выбор валидатора может влиять на результат. Наилучшим подходом для промежуточного кэша является использование в запросе своего собственного валидатора. Если сервер присылает отклик 304 (Not Modified), тогда кэш должен отправить свою уже проверенную копию клиенту со статусным кодом 200 (OK). Если сервер присылает отклик с новым объектом и валидатором кэша, промежуточный кэш должен сверить, тем не менее, полученный валидатор с тем, что прислал клиент, используя функцию сильного сравнения. Если валидатор клиента равен присланному сервером, тогда промежуточный кэш просто возвращает код 304 (Not Modified). В противном случае он присылает новый объект со статусным кодом 200 (OK).
Если запрос включает в себя директиву no-cache, в нем не должно быть min-fresh, max-stale или max-age.
В некоторых случаях, таких как периоды исключительно плохой работы сети, клиент может захотеть возвращать только те отклики, которые в данный момент находятся в памяти, и не перезагружать или перепроверять записи из исходного сервера. Для того чтобы сделать это, клиент может включить в запрос директиву only-if-cached. При получении такой директивы кэшу следует либо реагировать, используя кэшированную запись, которая соответствует остальным требованиям запроса, либо откликаться статусным кодом 504 (Gateway Timeout).
Однако если группа кэшей работает как унифицированная система с хорошей внутренней коннективностью, тогда такой запрос может быть переадресован в пределах группы кэшей
Так как кэш может быть сконфигурирован так, чтобы игнорировать времена жизни, заданные сервером, а запрос клиента может содержать директиву max-stale, протокол включает в себя механизм, который позволяет серверу требовать перепроверки записей в кэше для любого последующего применения. Когда в отклике, полученном кэшем, содержится директива must-revalidate, этот кэш не должен использовать эту запись для откликов на последующие запросы без сверки ее на исходном сервере. Таким образом, кэш должен выполнить перепроверку end-to-end каждый раз, если согласно значениям Expires или max-age, кэшированный отклик является устаревшим.
Директива must-revalidate необходима для поддержания надежной работы для определенных функций протокола. При любых обстоятельствах HTTP/1.1 кэш должен выполнять директиву must-revalidate. В частности, если кэш по какой-либо причине не имеет доступа к исходному серверу, он должен генерировать отклик 504 (Gateway Timeout).
Серверы должны посылать директиву must-revalidate, тогда и только тогда, когда неудача запроса перепроверки объекта может вызвать нарушение работы системы, например, не выполнение финансовой операции без оповещения об этом. Получатели не должны осуществлять любые автоматические действия, которые нарушают эту директиву, и не должны посылать непригодную копию объекта, если перепроверка не удалась.
Хотя это и не рекомендуется, агенты пользователя, работающие в условиях очень плохой коннективности, могут нарушать эту директиву, но, если это происходит, пользователь должен быть предупрежден в обязательном порядке, что присланный отклик возможно является устаревшим. Предупреждение должно посылаться в случае каждого непроверенного доступа, при этом следует требовать подтверждения от пользователя.
Директива proxy-revalidate имеет то же значение, что и must-revalidate, за исключением того, что она не применима для индивидуальных кэшей агентов пользователя.
Она может использоваться в отклике на подтвержденный запрос, чтобы разрешить кэшу пользователя запомнить и позднее прислать отклик без перепроверки (так как он был уже подтвержден однажды этим пользователем), в то же время прокси должен требовать перепроверки всякий раз при обслуживании разных пользователей (для того чтобы быть уверенным, что каждый пользователь был авторизован). Заметьте, что такие авторизованные отклики нуждаются также в директиве управления кэшем public для того, чтобы разрешить их кэширование.
13.9.5. Директива No-Transform
Разработчики промежуточных кэшей (прокси) выяснили, что полезно преобразовать тип среды для тел определенных объектов. Прокси может, например, преобразовать форматы изображения для того, чтобы сэкономить место в памяти кэша или чтобы уменьшить информационный поток в тихоходном канале. HTTP должен датировать такие преобразования, выполняемые без оповещения.
Серьезные операционные проблемы происходят, однако, когда такие преобразования производятся над телами объектов, предназначенных для определенного сорта приложений. Например, использующих медицинские изображения, предназначенные для анализа научных данных, а также тех, которые применяют авторизацию end-to-end, или требуют побитной совместимости с оригиналом.
Следовательно, если отклик содержит директиву no-transform, промежуточный кэш или прокси не должны изменять те заголовки, которые перечислены в разделе 12.5.2, так как они могут содержать директиву no-transform. Это предполагает, что кэш или прокси не должны изменять любую часть тела объекта, который имеет такие заголовки.
13.9.6. Расширения управления кэшем
Поле заголовка Cache-Control может быть расширено за счет использования одной или более лексем расширения, каждой из которых может быть присвоено определенное значение. Информационные расширения (те которые не требуют изменений в работе кэша) могут быть добавлены без изменения семантики других директив. Поведенческие расширения спроектированы для того, чтобы выполнять функции модификаторов существующих директив управления кэшем.
Новые директивы и стандартные директивы устроены так, что приложения, которые не воспринимают новую директиву, по умолчанию исполнят стандартную процедуру. Те же приложения, которые распознают новую директиву, воспринимают ее как модификацию стандартной процедуры. Таким путем расширения директив управления кэшем могут быть сделаны без изменения базового протокола.
Этот механизм расширений зависит от того, выполняет ли кэш все директивы управления, определенные для базовой версии HTTP. Предполагается, что кэш реализует определенные расширения и игнорирует все директивы, которые не может распознать.
Например, рассмотрим гипотетическую, новую директиву, названную "community", которая действует как модификатор директивы "private". Мы определяем эту новую директиву так, что в дополнение к стандартным возможностям индивидуальных кэшей, кэши, которые обслуживают группу (community), могут кэшировать их отклики. Исходный сервер, желающий позволить группе "UCI" использовать частные отклики на их общем кэше, может решить эту проблему, включив директиву управления кэшем: private, community="UCI".
Кэш, получив это поле заголовка, будет действовать корректно, если даже не понимает расширение "community", так как он видит и понимает директиву "private" и, таким образом, по умолчанию обеспечит безопасное функционирование.
Не распознанная директива управления должна игнорироваться. Предполагается, что любая директива, в том числе и не узнанная кэшем HTTP/1.1, имеет по умолчанию стандартную директиву-подмену, которая обеспечивает определенный уровень функциональности, когда директива-расширение не распознается.
13.10. Соединение
Поле общего заголовка Connection позволяет отправителю специфицировать опции, которые желательны для конкретного соединения. Заголовок Connection имеет следующую грамматику:
Connection-header = "Connection" ":" 1#(connection-token)
connection-token = token
Прокси-серверы HTTP/1.1 должны выполнить разбор поля заголовка Connection, прежде чем выполнить переадресацию, и для каждой лексемы соединения в этом поле убрать любые поля заголовка в сообщении с именами, совпадающими с этими лексемами.
Опции Connection отмечаются присутствием лексем соединения в поле заголовка Connection, а не какими-либо дополнительными полями заголовка, так как дополнительное поле заголовка может быть не послано, если нет параметров, ассоциированных с данной опцией соединения. HTTP/1.1 определяет опцию "close" (закрыть) для отправителя, чтобы сигнализировать о том, что соединение будет закрыто после завершения передачи отклика. Например, наличие
Connection: close
как в полях запроса, так и в полях отклика указывает на то, что соединение не следует рассматривать как "постоянное" (раздел 7.1) после завершения передачи данного запроса/отклика.
Приложения HTTP/1.1, которые не поддерживают постоянные соединения, должны содержать опцию соединения "close" в каждом сообщении.
13.11. Content-Base
Поле заголовка объекта Content-Base может быть использовано для спецификации базового URI, которое позволяет работать с относительными URL в пределах объекта. Это поле заголовка описано как Base в документе RFC 1808, который, как ожидается, будет пересмотрен.
Content-Base = "Content-Base" ":" absoluteURI
Если поле Content-Base отсутствует, базовый URI объекта определяется его Content-Location (если это Content-Location URI является абсолютным) или URI используется для инициации запроса. Заметьте, однако, что базовый URI содержимого в пределах тела объекта может быть переопределен.
13.12. Кодирование содержимого
Поле заголовка объекта Content-Encoding используется в качестве модификатора типа среды. Если это поле присутствует, его значение указывает, что тело объекта закодировано, и какой механизм декодирования следует применить, чтобы получить массив данных, ориентированный на тип среды, указанный в поле Content-Type. Поле Content-Encoding первоначально предназначалось для того чтобы архивировать документ без потери его идентичности с учетом типа среды, на которую он ориентирован.
Content-Encoding = "Content-Encoding" ":" 1#content-coding
Кодировки содержимого определены в разделе 2.5. Пример его использования приведен ниже
Content-Encoding: gzip
Content-Encoding (кодирование содержимого) является характеристикой объекта, задаваемой Request-URI. Обычно тело объекта заносится в память в закодированном виде и декодируется перед отображением или другим аналогичным использованием.
Если было применено множественное кодирование объекта, кодирование содержимого должно быть перечислено в том порядке, в котором оно было выполнено.
13.13. Язык содержимого
Поле заголовка объекта Content-Language описывает естественный язык(и) потенциальных читателей вложенного объекта. Заметьте, что это может быть совсем не эквивалентно всем языкам, использованным в теле объекта.
Content-Language = "Content-Language" ":" 1#language-tag
Языковые метки определены в разделе 2.10. Первоначальной целью поля Content-Language является предоставление пользователю возможности дифференцировать объекты согласно языковым предпочтениям. Таким образом, если содержимое тела предназначено только для аудитории, говорящей на датском языке, подходящим содержимым поля Content-Language может быть
Content-Language: da
Если поле Content-Language не задано, по умолчанию считается, что содержимое ориентировано на любую аудиторию. Это может значить, что отправитель не выделяет какой-либо естественный язык конкретно, или что отправитель не знает, какой язык предпочесть.
Список языков может быть предложен для текста, который предназначен для многоязыковой аудитории. Например, перевод "Treaty of Waitangi," представленный одновременно в оригинальной версии на маори и на английском, может быть вызван с помощью
Content-Language: mi, en
Однако только то, что в поле объекта перечислено несколько языков не означает, что объект предназначен для многоязыковой аудитории. Примером может быть языковый курс для начинающих, такой как "A First Lesson in Latin," который предназначен для англо-говорящей аудитории. В этом случае поле Content-Language должно включать только "en".
Поле Content-Language может быть применено к любому типу среды – оно не ограничено только текстовыми документами.
13.14. Длина содержимого
Содержимое поля заголовка объекта Content-Length указывает длину тела сообщения в октетах (десятичное число), посылаемое получателю, или в случае метода HEAD, размер тела объекта, который мог бы быть послан при запросе GET.
Content-Length = "Content-Length" ":" 1*DIGIT
Например
Content-Length: 3495
Приложениям следует использовать это поле для указания размера сообщения, которое должно быть послано вне зависимости от типа среды. Получатель должен иметь возможность надежно определить положение конца запроса HTTP/1.1, содержащего тело объекта, например, запрос использует Transfer-Encoding chunked или multipart body.
Любое значение Content-Length больше или равное нулю допустимо. Раздел 3.4 описывает то, как определить длину тела сообщения, если параметр Content-Length не задан.
Замечание. Значение этого поля заметно отличается от соответствующего определения в MIME, где оно является опционным, используемым в типе содержимого "message/external-body". В HTTP его следует посылать всякий раз, когда длина сообщения должна быть известна до начала пересылки.
13.15. Поле Content-Location
Поле заголовка объекта Content-Location может быть использовано для определения положения ресурса для объекта, вложенного в сообщение. В случае, когда ресурс содержит много объектов, и эти объекты в действительности имеют разные положения, по которым может быть осуществлен доступ, сервер должен предоставить поле Content-Location для конкретного варианта, который должен быть прислан. Кроме того сервер должен предоставить Content-Location для ресурса, соответствующего объекту отклика.
Content-Location = "Content-Location" ":"
( absoluteURI | relativeURI )
Если поле заголовка Content-Base отсутствует, значение Content-Location определяет также базовый URL для объекта (см. раздел 13.11).
Значение Content-Location не является заменой для исходного запрашиваемого URI, это лишь объявление положения ресурса, соответствующего данному конкретному объекту в момент запроса.
Будущие запросы могут использовать Content- Location URI, если нужно идентифицировать источник конкретного объекта.
Кэш не может предполагать, что объект с полем Content-Location, отличающимся от URI, который использовался для его получения, может использоваться для откликов на последующие запросы к этому Content-Location URI. Однако Content-Location может использоваться для того, чтобы отличить объекты, полученные из одного общего, как это описано в разделе 12.6.
Если Content-Location является относительным URI, URI интерпретируется с учетом значения Content-Base URI, присланного в отклике. Если значения Content-Base не предоставлено, относительный URI интерпретируется по отношению к Request-URI.
13.16. Content-MD5
Поле заголовка объекта Content-MD5, как это определено в RFC 1864 [23], является MD5-дайджестом тела объекта для целей обеспечения проверки end-to-end целостности сообщения MIC (message integrity check). Замечание. MIC привлекательна для регистрации случайных модификаций тела объекта при транспортировке, но не является гарантией против преднамеренных действий.)
| Content | MD5 = "Content-MD5" ":" md5-digest |
| md5digest | = |
Дайджест MD5 вычисляется на основе содержимого тела сообщения, с учетом любых кодировок содержимого, но исключая любые транспортные кодировки (Transfer-Encoding), которые могли быть использованы. Если сообщение получено в закодированном виде с использованием Transfer-Encoding, это кодирование должно быть удалено перед проверкой значения Content-MD5 для полученного объекта.
Это означает, что дайджест вычисляется для октетов тела объекта в том порядке, в каком они будут пересланы, если не используется транспортное кодирование.
HTTP расширяет RFC 1864 с тем, чтобы разрешить вычисление дайджеста для MIME-комбинации типов среды (например, multipart/* и message/rfc822), но это никак не влияет на способ вычисления дайджеста, описанного выше.
Замечание. Существует несколько следствий этого. Тело объекта для комбинированных типов может содержать много составных частей, каждая со своими собственными MIME и HTTP заголовками (включая заголовки Content-MD5, Content-Transfer-Encoding и Content-Encoding). Если часть тела имеет заголовок Content-Transfer-Encoding или Content-Encoding, предполагается, что содержимое этой части закодировано и она включается в дайджест Content-MD5 как есть. Поле заголовка Transfer-Encoding не применимо для частей тела объекта.
Замечание. Так как определение Content-MD5 является в точности тем же для HTTP и MIME (RFC 1864), существует несколько вариантов, в которых применение Content-MD5 к телам объектов HTTP отличается от случая MIME. Один вариант связан с тем, что HTTP, в отличие от MIME, не использует Content-Transfer-Encoding, а использует Transfer-Encoding и Content-Encoding. Другой - вызван тем, что HTTP чаще, чем MIME, использует двоичный тип содержимого. И, наконец, HTTP позволяет передачу текстовой информации с любым типом разрыва строк, а не только с каноническим CRLF. Преобразование всех разрывов строк к виду CRLF не должно делаться до вычисления или проверки дайджеста: тип оформления разрыва строк при расчете дайджеста должен быть сохранен.
13.17. Отрывок содержимого
Заголовок объекта Content-Range посылается с частью тела объекта и служит для определения того, где в теле объекта должен размещаться данный фрагмент. Он также указывает полный размер тела объекта. Когда сервер присылает клиенту частичный отклик, он должен описать как длину фрагмента, так и полный размер тела объекта.
| Content-Range | = "Content-Range" ":" content-range-spec |
| Content-range-spec | = byte-content-range-spec |
| byte-content-range-spec | = bytes-unit SP first-byte-pos "-" |
/p> last-byte-pos "/" entity-length
| entity-length | = 1*DIGIT |
Некорректной считается спецификация byte-content-range-spec, чье значение last-byte-pos меньше, чем его значение first-byte-pos, или значение длины объекта меньше или равно last-byte-pos. Получатель некорректной спецификации byte-content-range-spec должен игнорировать ее и любой текст, переданный вместе с ней. Примеры спецификации byte-content-range-spec, предполагающей, что объект содержит 1234 байт, приведены ниже:
The first 500 bytes: bytes 0-499/1234
The second 500 bytes: bytes 500-999/1234
All except for the first 500 bytes: bytes 500-1233/1234
The last 500 bytes: bytes 734-1233/1234
Когда сообщение HTTP включает в себя содержимое одного фрагмента (например, отклик на запрос одного фрагмента, или на запрос набора фрагментов, которые перекрываются без зазоров), это содержимое передается с заголовком Content-Range, а заголовок Content-Length несет в себе число действительно переданных байт. Например,
HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
Когда сообщение HTTP несет в себе содержимое нескольких фрагментов (например, отклик на запрос получения нескольких, не перекрывающихся фрагментов), они передаются как многофрагментное MIME-сообщение. Многофрагментный тип данных MIME используемый для этой цели, определен в этой спецификации как "multipart/byteranges". (Смотри приложение 16.2).
Клиент, который не может декодировать сообщение MIME multipart/byteranges, не должен запрашивать несколько байт-фрагментов в одном запросе.
Когда клиент запрашивает несколько фрагментов байт в одном запросе, серверу следует присылать их в порядке перечисления.
Если сервер игнорирует спецификацию byte-range-spec, из- за того, что она некорректна, сервер должен воспринимать запрос так, как если бы некорректного заголовка Range не существовало вовсе. (В норме это означает посылку отклика с кодом 200, содержащего весь объект). Причиной этого является то, что клиент может прислать такой некорректный запрос, только когда объект меньше чем объект, полученный по предыдущему запросу.
13.18. Тип содержимого
Поле заголовка объекта Content-Type указывает тип среды тела объекта, посланного получателю, или, в случае метода HEAD, тип среды, который был бы применен при методе GET.
Content-Type = "Content-Type" ":" media-type
Типы среды определены в разделе 2.7. Примером поля может служить
Content-Type: text/html; charset=ISO-8859-4
Дальнейшее обсуждение методов идентификации типа среды объекта приведено в разделе 6.2.1.
13.19. Дата
Поле общего заголовка Date представляет дату и время формирования сообщения, имеет ту же семантику, что и orig-date в RFC 822. Значение поля равно HTTP-date, как это описано в разделе 2.3.1.
Date = "Date" ":" HTTP-date
Пример
Date: Tue, 15 Nov 1994 08:12:31 GMT
Если сообщение получено через непосредственное соединение с агентом пользователя (в случае запросов) или исходным сервером (в случае откликов), дата может считаться текущей датой конца приема. Однако так как дата по определению является важной при оценке характеристик кэшированных откликов, исходный сервер должен включать поле заголовка Date в каждый отклик. Клиентам следует включать поле заголовка Date в сообщения, которые несут тело объекта запросов PUT и POST, но даже здесь это является опционным. Полученному сообщению, которое не имеет поля заголовка Date, следует присвоить дату. Это может сделать один из получателей, если сообщение будет кэшировано им, или внешним шлюзом.
Теоретически дата должна представлять момент времени сразу после генерации объекта. На практике поле даты может быть сформировано в любое время в процессе генерации сообщения.
Формат поля Date представляет собой абсолютную дату и время так, как это определено для даты HTTP в разделе 2.3. Оно должно быть послано в формате, описанном в документе RFC-1123 [8].
13.20. Поле ETag
Поле заголовка объекта ETag определяет метку объекта. Заголовки с метками объектов описаны в разделах 13.20, 13.25, 13.26 и 13.43. Метка объекта может использоваться для сравнения с другими объектами того же самого ресурса (см. раздел 12.8.2).
ETag = "ETag" ":" entity-tag
Примеры:
ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""
13.21. Поле Expires
Поле заголовка объекта Expires содержит дату/время с момента, когда отклик может считаться устаревшим. Устаревшая запись в кэше в норме не должна посылаться кэшем (а также прокси кэшем и кэшем агента пользователя), если только она не будет сначала перепроверена с помощью исходного сервера (или с помощью промежуточного кэша, который содержит свежую копию объекта). Дальнейшее обсуждение модели контроля пригодности записей содержится в разделе 12.2. Присутствие поля Expires не предполагает, что исходный ресурс изменит или удалит объект по истечении указанного времени.
Формат абсолютной даты и времени описан в разделе 2.3. Он должен следовать рекомендациям документа RFC1123:
Expires = "Expires" ":" HTTP-date
Примером реализации формата даты может служить
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Замечание. Если отклик содержит поле Cache-Control с директивой max-age, то эта директива переписывает значение поля Expires.
Клиенты HTTP/1.1 и кэши должны рассматривать некорректные форматы даты, в особенности те, что содержат нули, как относящиеся к прошлому (то есть, как "уже истекшие").
Для того, чтобы пометить отклик, как "уже с истекшим сроком", исходный сервер должен использовать дату Expires, которая равна значению заголовка Date. (Правила вычисления времени истечения пригодности записи смотри в разделе 12.2.4.)
Для того, чтобы пометить отклик как "всегда пригодный", исходный сервер должен использовать дату Expires приблизительно на один год позже момента посылки отклика.
Серверы HTTP/1. 1 не должны посылать отклики с датами в поле Expires, которые устанавливают время жизни более одного года.
Присутствие поля заголовка Expires со значением даты, относящейся к будущему, означает, что они могут быть занесены в кэш, если только не указано обратного в поле заголовка Cache-Control (раздел 13.9).
13.22. Поле From
Поле заголовка запроса From (если присутствует) должно содержать интернетовский e-mail адрес пользователя. Адрес должен иметь формат, описанный в документе RFC-822 (и дополненный в RFC-1123):
From = "From" ":" mailbox
Пример:
From: webmaster@w3.org
Это поле заголовка может быть использовано для целей регистрации процедур и как средство идентификации источников некорректных и нежелательных запросов. Не следует использовать его как ненадежную систему защиты доступа. Это поле предоставляет информацию о том, кто является ответственным за метод, использованный в данном запросе. В частности, агенты-роботы должны содержать этот заголовок, так чтобы с лицом, ответственным за работу робота, можно было связаться, в случае возникновения проблем на принимающем конце.
Интернетовский e-mail адрес в этом поле может не совпадать с Интернет-адресом ЭВМ, пославшей запрос. Например, когда запрос прошел через прокси, следует использовать адрес первичного отправителя.
Замечание. Клиенту не следует посылать поле заголовка From без одобрения пользователя, так как это может вызвать конфликт с интересами конфиденциальности пользователя или нарушить политику безопасности сети отправителя. Настоятельно рекомендуется, чтобы пользователь мог дезактивировать, активировать и модифицировать значение этого поля в любое время до запроса.
13.23. Поле Host
Поле заголовка запроса Host специфицирует ЭВМ в Интернет и номер порта запрашиваемого ресурса в виде, полученном из исходного URL, который выдал пользователь или который получен из указанного ресурса (в общем случае из HTTP URL, как это описано в разделе 2.2.2). Значение поля Host должно определять положение в сети исходного сервера или шлюза, заданное исходным URL.
Это позволяет исходному серверу или шлюзу различать внутренние URL, такие как корневые "/" URL сервера для ЭВМ, которым поставлен в соответствие один IP адрес.
Host = "Host" ":" host [ ":" port ] ; Раздел 2.2.2
Имя "ЭВМ" без последующего номера порта предполагает значение порта по умолчанию для заданного вида сервиса (напр., "80" для HTTP URL). Например, запрос исходного сервера должен включать в себя:
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
Клиент должен включать поле заголовка Host во все сообщения-запросы HTTP/1.1 в Интернет (т.е., в любое сообщение, соответствующее запросу URL, который включает в себя Интернет-адрес ЭВМ, услуги которой запрашиваются). Если поле Host отсутствует, прокси HTTP/1.1 должен добавить его в сообщение-запрос до того, как переадресует запрос дальше в Интернет. Все серверы HTTP/1.1, которые базируются в Интернет, должны откликаться статусным кодом 400 на любое сообщение-запрос HTTP/1.1, в котором отсутствует поле Host.
О других требованиях относительно поля Host смотри раздел 4.2 и 16.5.1.
13.24. Поле If-Modified-Sinc
Поле заголовка запроса If-Modified-Since используется с методом GET, для того чтобы сделать его условным. Если запрошенный объект не был модифицирован со времени, указанного в этом поле, объект не будет прислан сервером, вместо этого будет послан отклик 304 (not modified) без какого-либо тела сообщения.
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
Пример поля:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Метод GET с заголовком If-Modified-Since и без заголовка Range требует, чтобы идентифицированный объект был передан, только в случае его модификации после даты, указанной в заголовке If-Modified-Since. Алгоритм определения этого включает в себя следующие шаги.
Если запрос приводит к чему-то отличному от статусного отклика 200 (OK), или если переданная дата If-Modified-Since некорректна, отклик будет в точности тот же, что и для обычного GET.
Дата раньше текущего времени сервера является некорректной.
Если объект был модифицирован после даты If-Modified-Since, отклик будет в точности тем же, что и для обычного GET.
Если объект не был модифицирован после корректно указанной даты If-Modified-Since, сервер должен прислать отклик 304 (Not Modified).
Целью этой функции является эффективная актуализация кэшированной информации с минимальными издержками.
Заметьте, что поле заголовка запроса Range модифицирует значение If-Modified-Since. Более детально эта проблема рассмотрена в разделе 13.36.
Заметьте, что время If-Modified-Since интерпретируются сервером, чьи часы могут быть не синхронизованы с часами клиента.
Если клиент использует произвольную дату в заголовке If-Modified-Since вместо даты взятой из заголовка Last-Modified для текущего запроса, тогда клиенту следует остерегаться того, что эта дата интерпретируется согласно представлениям сервера о временной шкале. Клиенту следует учитывать не синхронность часов и проблемы округления, связанные с различным кодированием времени клиентом и сервером. Это предполагает возможность быстрого изменения условий, когда документ изменяется между моментом первого запроса и датой If-Modified-Since последующего запроса, а также возможность трудностей, связанных с относительным сбоем часов, если дата If-Modified-Since получена по часам клиента (без поправки на показания часов сервера). Поправки для различных временных базисов клиента и сервера желательно делать с учетом времени задержки в сети.
13.25. Поле If-Match
Поле заголовка запроса If-Match используется с методом, для того чтобы сделать его условным. Клиент, который имеет один или более объектов, полученных ранее из ресурса, может проверить, является ли один из этих объектов текущим, включив список связанных с ним меток в поле заголовка If-Match. Целью этой функции является эффективная актуализация кэшированной информации с минимальными издержками. Она используется также в запросах актуализации с целью предотвращения непреднамеренной модификации не той версии ресурса что нужно.
Значение "*" соответствует любому текущему объекту ресурса.
If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
Если какая-то метка объекта совпадает с меткой объекта, который прислан в отклике на аналогичный запрос GET (без заголовка If-Match), или если задана "*" и какой-то текущий объект существует для данного ресурса, тогда сервер может реализовать запрошенный метод, как если бы поля заголовка If-Match не существовало.
Сервер должен использовать функцию сильного сравнения (см. раздел 2.11) для сопоставления меток объекта в If-Match.
Если ни одна из меток не подходит, или если задана "*" и не существует никакого текущего объекта, сервер не должен реализовывать запрошенный метод, а должен прислать отклик 412 (Precondition Failed). Это поведение наиболее полезно, когда клиент хочет помешать актуализующему методу, такому как PUT, модифицировать ресурс, который изменился после последнего доступа к нему клиента.
Если запрос без поля заголовка If-Match выдает в результате нечто отличное от статуса 2xx, тогда заголовок If-Match должен игнорироваться.
"If-Match: *" означает, что метод должен быть реализован, если представление, выбранное исходным сервером (или кэшем, возможно с привлечением механизма Vary, см. раздел 13.43), существует, и не должен быть реализован, если выбранного представления не существует.
Запрос, предназначенный для актуализации ресурса (напр., PUT) может включать в себя поле заголовка If-Match, чтобы сигнализировать о том, что метод запроса не должен быть применен, если объект, соответствующий значению If-Match (одиночная метка объекта), не является более представлением этого ресурса. Это позволяет пользователям указывать, что они не хотят, чтобы запрос прошел успешно, если ресурс был изменен без их уведомления. Примеры:
If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *
13.26. Поле If-None-Match
Поле заголовка запроса If-None-Match используется для формирования условных методов.
Клиент, который имеет один или более объектов, полученных ранее из ресурса, может проверить, что ни один из этих объектов не является текущим, путем включения списка их ассоциированных меток в поле заголовка If-None-Match. Целью этой функции является эффективная актуализация кэшированной информации с минимальной избыточностью. Она также используется при актуализации запросов с тем, чтобы предотвратить непреднамеренную модификацию ресурса, о существовании которого не было известно.
Значение "*" соответствует любому текущему объекту ресурса.
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
Если какая-либо метка объекта соответствует метке объекта, который был прислан в отклике на аналогичный запрос GET (без заголовка If-None-Match) или если задана "*" и существует какой-то текущий объект данного ресурса, тогда сервер не должен реализовывать запрошенный метод. Вместо этого, если методом запроса был GET или HEAD, серверу следует реагировать откликом 304 (Not Modified), включая поля заголовков объекта, ориентированные на кэш (в частности ETag). Для всех других методах запроса сервер должен откликаться статусным кодом 412 (Precondition Failed).
По поводу правил того, как определять соответствие двух меток объектов смотри раздел 12.8.3. С запросами GET и HEAD должна использоваться только функция слабого сравнения.
Если не подходит ни одна из меток объекта или если задана "*" и не существует ни одного текущего объекта, сервер может выполнить запрошенный метод так, как если бы поля заголовка If-None-Match не существовало.
Если запрос без поля заголовка If-None-Match, даст результат отличный от статусного кода 2xx, тогда заголовок If-None-Match должен игнорироваться.
"If-None-Match: *" означает, что метод не должен реализовываться, если представление, выбранное исходным сервером (или кэшем, возможно использующим механизм Vary, см. раздел 13.43), существует, и должен быть реализован, если представления не существует.
Эта функция может быть полезной для предотвращения конкуренции между операциями PUT.
Примеры:
If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *
13.27. Заголовок If-Range
Если клиент имеет частичную копию объекта в своем кэше и хочет иметь полную свежую копию объекта, он может использовать заголовок запроса Range с условным GET (используя If-Unmodified-Since и/или If-Match.) Однако если условие не выполняется, из-за того, что объект был модифицирован, клиенту следует послать второй запрос, чтобы получить все текущее содержимое тела объекта.
Заголовок If-Range позволяет клиенту заблокировать второй запрос. По существу это означает, что "если объект не изменился, следует посылать мне часть, которой у меня нет, в противном случае пришлите мене всю новую версию объекта".
If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
Если клиент не имеет метки объекта, но имеет дату Last-Modified, он может использовать эту дату в заголовке If-Range. Сервер может отличить корректную дату HTTP от любой формы метки объекта, рассмотрев не более двух символов. Заголовок If-Range следует использовать только совместно с заголовком Range, и его следует игнорировать, если запрос не содержит в себе этот заголовок, или если сервер не поддерживает операции с фрагментами.
Если метка объекта, представленная в заголовке If-Range, соответствует текущей метке, тогда сервер должен обеспечить специфицированный фрагмент объекта, используя отклик 206 (Partial content). Если метка объекта не подходит, сервер должен прислать полный объект со статусным кодом 200 (OK).
13.28. Поле If-Unmodified-Since
Поле заголовка запроса If-Unmodified-Since используется для того, чтобы формировать условные методы. Если запрошенный ресурс не был модифицирован с момента, указанного в поле, сервер должен произвести запрошенную операцию, так как если бы заголовок If-Unmodified-Since отсутствовал.
Если запрошенный объект был модифицирован после указанного времени, сервер не должен выполнять запрошенную операцию и должен прислать отклик 412 (Precondition Failed).
If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
Примером поля может служить:
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Если запрос завершается чем-то отличным от статусного кода 2xx (т.е., без заголовка If-Unmodified-Since), заголовок If-Unmodified-Since следует игнорировать. Если специфицированная дата некорректна, заголовок также игнорируется.
13.29. Поле Last-Modified
Поле заголовка объекта Last-Modified указывает на дату и время, при которых, по мнению исходного сервера, данный объект был модифицирован.
Last-Modified = "Last-Modified" ":" HTTP-date
Пример его использования
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Точное значение этого заголовка зависит от реализации исходного сервера и природы ресурса. Для файлов, это может быть дата последней модификации файловой системы. Для объектов с динамическими встроенными частями это может время последней модификации одной из встроенных компонент. Для шлюзов баз данных это может быть метка последней модификации рекорда. Для виртуальных объектов это может быть время последнего изменения внутреннего состояния.
Исходный сервер не должен посылать дату Last-Modified, которая позже, чем время формирования сообщения сервера. В таких случаях, когда последняя модификация объекта указывает некоторое на время в будущем, сервер должен заменить дату на время формирования сообщения.
Исходный сервер должен получить значение Last-Modified объекта как можно ближе по времени к моменту генерации значения Date отклика. Это позволяет получателю выполнить точную оценку времени модификации объекта, в особенности, если объект был изменен буквально накануне формирования отклика.
Серверы HTTP/1.1 должны посылать поле Last-Modified всякий раз, когда это возможно.
13.30. Поле Location
Поле заголовка отклика Location используется для переадресации запроса на сервер, отличный от указанного в Request-URI, или для идентификации нового ресурса.
В случае отклика 201 (Created), поле Location указывает на новый ресурс, созданный в результате запроса. Для откликов 3xx поле Location должно указывать предпочтительные URL сервера для автоматической переадресации на ресурс. Значение поля включает одинарный абсолютный URL.
Location = "Location" ":" absoluteURI
Например
Location: http://www.w3.org/pub/WWW/People.html
Замечание. Поле заголовка Content-Location (раздел 13.15) отличается от поля Location в том, что Content-Location идентифицирует исходное положение объекта, заключенное в запросе. Следовательно, отклик может содержать поля заголовка как Location, так и Content-Location. Требования некоторых методов изложены также в разделе 12.10.
13.31. Поле Max-Forwards
Поле заголовка запроса Max-Forwards может использоваться с методом TRACE (раздел 13.31) ,чтобы ограничить число прокси или шлюзов, которые могут переадресовывать запрос. Это может быть полезным, когда клиент пытается отследить путь запроса в случае возникновения различных проблем.
Max-Forwards = "Max-Forwards" ":" 1*DIGIT
Значение Max-Forwards представляет собой целое десятичное число, которое указывает сколько еще раз запрос можно переадресовать.
Каждый прокси или шлюз получатель запроса TRACE, содержащего поле заголовка Max-Forwards, должен проверить и актуализовать его величину прежде, чем переадресовывать запрос. Если полученная величина равна нулю, получателю не следует переадресовывать запрос. Вместо этого, ему следует откликнуться как конечному получателю статусным кодом 200 (OK), содержащим полученное сообщение-запрос в качестве тела отклика (как это описано в разделе 8.8). Если полученное значение больше нуля, тогда переадресованное сообщение должно содержать актуализованное значение поля Max-Forwards (уменьшенное на единицу).
Поле заголовка Max-Forwards следует игнорировать для всех других методов определенных в данной спецификации и для всех расширений методов, для которых это не является частью определения метода.
13.32. Поле Pragma
Поле общего заголовка Pragma используется для включения специальных директив (зависящих от конкретной реализации), которые могут быть применены ко всем получателям вдоль цепочки запрос/отклик. Все директивы pragma специфицируют с точки зрения протокола опционное поведение. Однако некоторые системы могут требовать, чтобы поведение соответствовало директивам:
| Pragma | = "Pragma" ":" 1#pragma-directive |
| pragma-directive | = "no-cache" | extension-pragma |
| extension-pragma | = token [ "=" ( token | quoted-string ) ] |
Нельзя специфицировать директиву pragma для какого-то отдельного получателя. Однако любая директива pragma неприемлемая для получателя должна им игнорироваться.
Клиенты HTTP/1.1 не должны посылать заголовок запроса Pragma. Кэши HTTP/1.1 должны воспринимать "Pragma: no-cache", как если бы клиент послал "Cache-Control: no-cache". Никаких новых директив Pragma в HTTP определено не будет.
13.33. Поле Proxy-Authenticate
Поле заголовка отклика Proxy-Authenticate должно быть включено в качестве части отклика 407 (Proxy Authentication Required). Значение поля состоит из вызова, который указывает схему идентификации, и параметров, применимых в прокси для данного Request-URI.
Proxy-Authenticate = "Proxy-Authenticate" ":" challenge
Процесс авторизованного доступа HTTP описан в разделе 10. В отличие от WWW-Authenticate, поле заголовка Proxy-Authenticate применимо только к текущему соединению и не может быть передано другим клиентам.
Однако, промежуточному прокси может быть нужно получить свои собственные авторизационные параметры с помощью запроса у ниже расположенного клиента, который при определенных обстоятельствах может проявить себя как прокси, переадресующий поле заголовка Proxy-Authenticate.
13.34. Поле Proxy-Authorization
Поле заголовка запроса Proxy-Authorization позволяет клиенту идентифицировать себя (или его пользователя) прокси, который требует авторизации. Значение поля Proxy-Authorization состоит из автризационных параметров, содержащих идентификационную информацию агента пользователя для прокси и/или области (realm) запрошенного ресурса.
Proxy-Authorization = "Proxy-Authorization" ":" credentials
Процесс авторизации доступа HTTP описан в разделе 10. В отличие от Authorization, поле заголовка Proxy-Authorization применимо только к следующему внешнему прокси, который требует авторизации с помощью поля Proxy-Authenticate. Когда работает несколько прокси, объединенных в цепочку, поле заголовка Proxy-Authorization используется первым внешним прокси, который предполагает получение авторизационных параметров. Прокси может передать эти параметры из запроса клиента следующему прокси, если существует механизм совместной авторизации при обслуживании данного запроса.
13.35. Поле Public
Поле заголовка отклика Public содержит список методов, поддерживаемых сервером. Задачей этого поля является информирование получателя о возможностях сервера в отношении необычных методов. Перечисленные методы могут быть, а могут и не быть применимыми к Request-URI. Поле заголовка Allow (раздел 13.7) служит для указания методов, разрешенных для данного URI.
| Public | = "Public" ":" 1#method |
Public: OPTIONS, MGET, MHEAD, GET, HEAD
Это поле заголовка применяется для серверов, непосредственно соединенных с клиентом, (т.е., ближайших соседей в цепи соединения). Если отклик проходит через прокси, последний должен либо удалить поле заголовка Public или заменить его полем, характеризующим его собственные возможности.
13.36. Фрагмент
13.36.1. Фрагменты байт
Так как все объекты HTTP в процессе передачи представляют собой последовательности байт, концепция фрагментов является существенной для любого объекта HTTP. Однако не все клиенты и серверы нуждаются в поддержке операций с фрагментами.
Спецификации байтовых фрагментов в HTTP относятся к последовательностям байт в теле объекта не обязательно то же самое что и тело сообщения.
Операция с байтовыми фрагментами может относиться к одному набору байт или к нескольким таким наборам в пределах одного объекта.
| ranges-specifier | = byte-ranges-specifier |
| byte-ranges-specifier | = byte-sunit "=" byte-range-set |
| byte-range-set | = 1#( byte-range-spec | suffix-byte-range-spec ) |
| byte-range-spec | = first-byte-pos "-" [last-byte-pos] |
| first-byte-pos | = 1*DIGIT |
| last-byte-pos | = 1*DIGIT |
Если присутствует значение last-byte-pos, оно должно быть больше или равно значению first-byte-pos в спецификации byte-range-spec, в противном случае спецификация byte-range-spec не корректна. Получатель некорректной спецификации byte-range-spec должен ее игнорировать.
Если значение last-byte-pos отсутствует, или если значение больше или равно текущей длине тела объекта, значение last-byte-pos берется на единицу меньше текущего значения длины тела объекта в байтах.
При выборе last-byte-pos, клиент может ограничить число копируемых байт, если не известна длина объекта.
suffix-byte-range-spec = "-" suffix-length
suffix-length = 1*DIGIT
Спецификация suffix-byte-range-spec используется для задания суффикса тела объекта с длиной, заданной значением suffix-length. (То есть, эта форма специфицирует последние N байтов тела объекта.) Если объект короче заданной длины суффикса, то в качестве суффикса используется все тело объекта.
Примеры значений byte-ranges-specifier (предполагается, что длина тела объекта равна 10000):
Первые 500 байтов (относительные позиции 0-499, включительно): bytes=0-499
Вторые 500 байтов (относительные позиции 500-999, включительно): bytes=500-999
Последние 500 байтов (относительные позиции 9500-9999, включительно): bytes=-500
или
bytes=9500-
Первые и последние байты (байты 0 и 9999): bytes=0-0,-1
Несколько легальных, но неканонических спецификаций вторых 500 байт (относительные позиции 500-999, включительно): bytes=500-600,601-999; bytes=500-700,601-999
13.36.2. Запросы получения фрагментов
Информационные запросы HTTP, использующие условные или безусловные методы GET могут заказывать один или более субфрагментов объекта, а не целый объект, используя заголовок запроса Range:
| Range | = "Range" ":" ranges-specifier |
Если сервер поддерживает заголовки Range и специфицированный фрагмент или фрагменты подходят для данного объекта, то:
Присутствие заголовка Range в безусловном GET допускает модификацию того, что прислано. Другими словами отклик может содержать статусный код 206 (Partial Content) вместо 200 (OK).
Присутствие заголовка Range в условном GET (запрос использует If-Modified-Since, If-None-Match, If-Unmodified-Since и/или If-Match) модифицирует то, что прислано GET в случае успешного завершения при выполнении условия (TRUE). Это не влияет на отклик 304 (Not Modified), если условие не выполнено (FALSE).
В некоторых случаях более удобно использовать заголовок If-Range (см. раздел 13.27).
Если прокси, который поддерживает фрагменты, получает запрос Range, переадресует запрос внешнему серверу и получает в ответ весь объект, ему следует прислать запрашиваемый фрагмент клиенту.
Он должен запомнить весь полученный отклик в своем кэше, если отклик совместим с политикой записи в его кэш.
13.37. Поле Referer
Поле заголовка запроса Referer позволяет клиенту специфицировать (для пользы сервера) адрес (URI) ресурса, из которого был получен Request-URI. Заголовок запроса Referer позволяет серверу генерировать список обратных связей с ресурсами для интереса, ведения дневника, оптимизации кэширования и т.д.. Он позволяет также заставить работать устаревшие или дефектные связи. Поле Referer не должно посылаться, если Request-URI был получен от источника, который не имеет своего собственного URI, такого, например, как ввод с пользовательского терминала.
| Referer | = "Referer" ":" ( absoluteURI | relativeURI ) |
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
Если значением поля является частичный URI, его следует интерпретировать относительно Request-URI. URI не должен включать фрагментов.
Замечание. Так как первоисточник связи может быть конфиденциальной информацией или может раскрывать другой источник частной информации, настоятельно рекомендуется, чтобы пользователь имел возможность решать, посылать поле Referer или нет. Например, клиент-броузер может иметь кнопку-переключатель для открытого или анонимного просмотра, которая управляет активацией/дезактивацией посылки информации Referer и From.
13.38. Поле Retry-After
Поле заголовка отклика Retry-After может использоваться с кодом статуса 503 (Service Unavailable) с тем, чтобы указать, как еще долго данная услуга предполагается быть недоступной для запрашивающего клиента. Значением этого поля может быть либо дата HTTP либо целое число секунд (в десятичном исчислении) после отправки отклика.
| Retry-After | = "Retry-After" ":" ( HTTP-date | delta-seconds ) |
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
В последнем примере задержка равна двум минутам.
13.39. Поле Server
Поле заголовка отклика Server содержит информацию о программном обеспечении, используемым исходным сервером для обработки запросов.
Поле может содержать коды многих продуктов (раздел 2.8), комментарии, идентифицирующие сервер, и некоторые важные субпродукты. Коды программных продуктов перечисляются в порядке важности приложений.
| Server | = "Server" ":" 1*( product | comment ) |
Server: CERN/3.0 libwww/2.17
Если отклик переадресуется через прокси, приложение прокси не должно модифицировать заголовок отклика сервера. Вместо этого ему следует включить в отклик поле Via (как это описано в разделе 13.44).
Замечание. Раскрытие конкретной версии программного обеспечения сервера может облегчить атаки против программных продуктов, для которых известны уязвимые места. Разработчикам серверов рекомендуется сделать это поле конфигурируемой опцией.
13.40. Поле Transfer-Encoding (Транспортное кодирование)
Поле общего заголовка Transfer-Encoding указывает, какой тип преобразования (если таковое использовано) применен к телу сообщения, для того чтобы безопасно осуществить передачу между отправителем и получателем. Это поле отличается от Content-Encoding тем, что транспортное кодирование является параметром сообщения, а не объекта.
Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
Транспортное кодирование определено в разделе 2.6. Например:
Transfer-Encoding: chunked
Многие старые приложения HTTP/1.0 не воспринимают заголовок Transfer-Encoding.
13.41. Заголовок Upgrade (Актуализация)
Общий заголовок Upgrade позволяет клиенту специфицировать то, какие дополнительные коммуникационные протоколы он поддерживает и хотел бы использовать, если сервер найдет их подходящими. Сервер должен использовать поле заголовка Upgrade в отклике 101 (Switching Protocols) для указания того, какие протоколы активны.
| Upgrade | = "Upgrade" ":" 1#product |
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
Поле заголовка Upgrade предназначено для обеспечения простого механизма перехода от протокола HTTP/1.1 к некоторым другим. Это достигается путем разрешения клиенту объявлять о намерении использовать другой протокол, например, более позднюю версию HTTP с большим старшим кодом версии, даже если текущий запрос выполнен с использованием HTTP/1.1.
Это облегчает переходы между несовместимыми протоколами за счет разрешения клиенту инициировать запрос в более широко поддерживаемом протоколе, в то же время, указывая серверу, что он предпочел бы использовать протокол "получше", если таковой доступен (где слово "получше" определяется сервером, возможно согласно природы метода и/или запрашиваемого ресурса).
Поле заголовка Upgrade воздействует только на переключающий протокол прикладного уровня транспортного слоя существующег соединения. Upgrade не может быть использовано для требования изменения протокола, его восприятие и использование сервером является опционным. Совместимость и природа прикладного уровня коммуникаций после смены протокола зависит исключительно от нового выбранного протокола, хотя первым действием после такой замены должен быть отклик на исходный запрос HTTP, содержащий поле заголовка Upgrade.
Поле Upgrade применимо только к текущему соединению. Следовательно, ключевое слово upgrade должно содержаться в поле заголовка Connection (раздел 13.10) всякий раз, когда поле Upgrade присутствует в сообщении HTTP/1.1.
Поле заголовка Upgrade не может использоваться для указания смены протокола в другом соединении. Для этой цели более приемлемы отклики переадресации с кодами 301, 302, 303 или 305.
Эта спецификация определяет протокол с именем "HTTP" при работе с семейством протоколов для передачи гипертекста (Hypertext Transfer Protocols), как это определено в правилах работы с версиями HTTP раздела 2.1 и для будущих усовершенствований этой спецификации. В качестве имени протокола может использоваться любая лексема, однако она будет работать, только если клиент и сервер ассоциируют это имя с одним и тем же протоколом.
13.42. Поле User-Agent (Агент пользователя)
Поле заголовка отклика User-Agent содержит информацию об агенте пользователя, инициировавшем запрос. Это нужно для целей сбора статистических данных, отслеживания нарушений протокола и автоматического распознавания агентов пользователя.
Агентам пользователя рекомендуется включать это поле в запросы. Поле может содержать несколько кодов продуктов (раздел 2.8), комментарии, идентифицирующие агента и любые субпродукты, которые образуют существенную часть агента пользователя. Согласно договоренности коды программных продуктов перечисляются в порядке их важности для идентифицируемого приложения.
| User-Agent | = "User-Agent" ":" 1*( product | comment ) |
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
13.43. Поле Vary
Поле заголовка отклика Vary используется сервером для того, чтобы сигнализировать о том, что отклик выбран из числа имеющихся представлений с помощью механизма согласования под управлением сервера (раздел 11). Имена полей, перечисленные в заголовках Vary, являются такими заголовками запроса. Значение поля Vary указывает на то, что данный набор полей заголовка ограничивает пределы, в которых могут варьироваться представления, или что пределы вариации не специфицированы ("*") и, таким образом, могут модифицироваться в широких пределах для будущих запросов.
| Vary | = "Vary" ":" ( "*" | 1#field-name ) |
Набор полей заголовка, перечисленных в поле Vary известен как "выбирающие" заголовки запроса.
Когда кэш получает последующий запрос, чей Request-URI специфицирует одну или более записей кэша, включая заголовок Vary, кэш не должен использовать такую запись для формирования отклика на новый запрос.
Он это должен делать, если только все заголовки, перечисленные в кэшированном заголовке Vary, присутствуют в новом запросе и все заголовки отбора предшествующих запросов совпадают с соответствующими заголовками нового запроса.
Сортирующие заголовки от двух запросов считаются соответствующими, тогда и только тогда, когда сортирующие заголовки первого запроса могут быть преобразованы в сортирующие заголовки второго запроса с помощью добавления или удаления строчных пробелов LWS (Linear White Space) в местах, где это допускается соответствующими правилами BNF (Backus-Naur Form) и/или, комбинируя несколько полей заголовка согласно требованиям на построение сообщения из раздела 3.2.
Vary "*" означает, что не специфицированные параметры, возможно отличающиеся от содержащихся в полях заголовка (напр., сетевой адрес клиента), играют роль при выборе представления отклика. Последующие запросы данного ресурса могут быть правильно интерпретированы только исходным сервером, а кэш должен переадресовать запрос (возможно условно), даже когда он имеет свежий кэшированный отклик для данного ресурса. Об использовании заголовка кэшами см. раздел 12.6.
Значение поля Vary, состоящее из списка имен полей сигнализирует о том, что представление, выбранное для отклика, базируется на алгоритме выбора, который рассматривает только значения перечисленные в поле заголовка запроса. Кэш может предполагать, что тот же выбор будет сделан для будущих запросов с теми же значениями имен полей, для периода времени, в течение которого отклик остается свежим.
Имена полей не ограничены набором стандартных полей заголовков запросов, определенных в данной спецификации. Имена полей могут быть записаны строчными или прописными буквами.
13.44. Поле Via
Поле общего заголовка Via должно быть использовано шлюзами или прокси для указания промежуточных протоколов и получателей на пути от агента пользователя к серверу, которому адресован запрос, и между исходным сервером и клиентом в случае отклика.
Это аналогично полю "Received" документа RFC 822 и предназначено для использования при трассировке переадресаций сообщений, исключения петель запроса и идентификации протокольных возможностей всех отправителей вдоль цепочки запрос/отклик.
| Via | = "Via" ":" 1#( received-protocol received-by [ comment ] ) |
| received-protocol | = [ protocol-name "/" ] protocol-version |
| protocol-name | = token |
| protocol-version | = token |
| received-by | = ( host [ ":" port ] ) | pseudonym |
| pseudonym | = token |
Запись "protocol-name" является опционной, тогда и только тогда, когда это "HTTP". Поле "received-by" обычно соответствует ЭВМ и номеру порта сервера получателя или клиента, который переадресует сообщение. Однако, если настоящее имя ЭВМ считается конфиденциальной информацией, оно может быть заменено псевдонимом. Если номер порта не задан, можно предполагать, что используется значение по умолчанию для данного протокола (received-protocol).
Значения поля Via представляет каждый прокси или шлюз, который переадресовывал сообщение. Каждый получатель должен присоединить свою информацию так, что конечный результат оказывается упорядоченным согласно последовательности переадресующих приложений.
Комментарии могут быть использованы в поле заголовка Via для идентификации программ получателя прокси или шлюза аналогично полям User-Agent и Server header. Однако, все комментарии в поле Via являются опционными и могут быть удалены любым получателем перед тем, как переадресовать сообщение.
Например, сообщение-запрос может быть послано от агента пользователя HTTP/1.0 программе внутреннего прокси с именем "fred", которая использует HTTP/1.1 для того, чтобы переадресовать запрос общедоступному прокси с именем nowhere.com, который завершает процесс переадресации запроса исходному серверу www.ics.uci.edu.
Запрос, полученный www.ics.uci. edu будет тогда иметь следующее поле заголовка Via:
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Прокси и шлюзы, используемые как средства сетевой защиты (firewall) не должны по умолчанию переадресовывать имена ЭВМ и портов в пределах области firewall. Эта информация может передаваться, если это непосредственно позволено. Если это не разрешено, запись "received-by" для ЭВМ в зоне действия firewall должна быть заменена соответствующим псевдонимом.
Для организаций, которые имеют жесткие требования к защите конфиденциальности и сокрытию внутренней структуры, прокси может комбинировать субпоследовательность поля заголовка Via с идентичными значениями "received-protocol" в единую запись. Например,
Via: 1.0 vanya, 1.1 manya, 1.1 dunya, 1.0 sonya
Приложениям не следует комбинировать несколько записей, если они только не находятся под единым административным контролем и имена ЭВМ уже заменены на псевдонимы. Приложения не должны комбинировать записи, которые имеют различные значения "received-protocol".
13.45. Поле Warning (Предупреждение)
Поле заголовка отклика Warning используется для переноса дополнительной информации о состоянии отклика, которая может отражать статусный код. Эта информация обычно служит для предупреждения о возможной потере семантической прозрачности из-за операций кэширования. Заголовки Warning посылаются с откликами, используя:
| Warning | = "Warning" ":" 1#warning-value |
| warning-value | = warn-code SP warn-agent SP warn-text |
| warn-code | = 2DIGIT |
| warn-agent | = ( host [ ":" port ] ) | pseudonym |
| warn-text | = quoted-string |
Запись warn-text производится на естественном языке и с применением символьного набора, приемлемого для принимающего отклик лица. Это решение может базироваться на какой-то имеющейся информации, такой как положение кэша или пользователя, поле запроса Accept-Language, поле отклика Content-Language и т.д.
Языком по умолчанию является английский, а символьным набором - ISO-8859-1.
Если используется символьный набор отличный от ISO-8859-1, он должен быть закодирован в warn-text с использованием метода, описанного в RFC-1522 [14].
Любой сервер или кэш может добавить заголовки Warning к отклику. Новые заголовки Warning должны добавляться после любых существующих заголовков Warning. Кэш не должен уничтожать какие-либо заголовки, которые он получил в отклике. Однако, если кэш успешно перепроверил запись, ему следует удалить все заголовки Warning, присоединенные ранее, за исключением специальных кодов Warning. Он должен добавить к записи новые заголовки Warning, полученные с откликом перепроверки. Другими словами заголовками Warning являются те, которые были бы получены в отклике на запрос в данный момент.
Когда к отклику подключено несколько заголовков Warning, агенту пользователя следует отображать их столько, сколько возможно, для того чтобы они появились в отклике. Если невозможно отобразить все предупреждения, агент пользователя должен следовать следующим эвристическим правилам:
Предупреждения, которые появляются в отклике раньше, имеют приоритет перед теми, что появляются позже.
Предупреждения, с предпочитаемым пользователем символьным набором имеют приоритет перед предупреждениями с другими наборами, но с идентичными warn-codes и warn-agents.
Системы, которые генерируют несколько заголовков Warning, должны упорядочить их с учетом ожидаемого поведения агента пользователя.
Далее представлен список определенных в настоящее время кодов предупреждений, каждый из которых сопровождается рекомендуемым текстом на английском языке и описанием его значения.
Параллельный сетевой интерфейс HIPPI
4.1.7 Параллельный сетевой интерфейс HIPPI
Все рассматриваемые до сих пор системы передачи информации использовали исключительно последовательный код. На разных этапах эволюции телекоммуникаций предпочтение отдавалось и параллельному и последовательному методам обмена данными. В данный момент параллельный интерфейс сохранился только для подключения принтеров. Главным преимуществом последовательных схем передачи информации является экономия на кабелях. Ниже описан еще один стандарт, где применен параллельный интерфейс (начало разработки относится к 1987 году). HIPPI (high performance parallel interface, смотри ftp.network.com;
http://www.cern.ch/hsi/hippi/spec/introduc.htm; RFC-2067, IP over HIPPI, J.Renwick; RFC-1374, IP and ARP on HIPPI, J.Renwick, ANSI x3t9.3/90-043, 1990 и X3t9.3/91-005) представляет собой быстродействующий параллельный интерфейс, рассчитанный на пропускную способность 800 Мбит/с (но возможны версии со 100, 200 400 и 1600 Мбит/с). Разработка интерфейса выполнена в Лос-Аламосе. Позднее на базе этого интерфейса была подготовлена идеология сети.
Длина кода, передаваемого за один такт в HIPPI, составляет 32 разряда (версия HIPPI, рассчитанная на скорость 1600 Мбит/с, имеет длину кода 64 бита). Все пересылки являются симплексными. Существует стандарт Superhippi (HIPPI-6400, 6,4 Гбайт/с), который описывает систему передачи данных в 8 раз более быстродействующую, чем HIPPI. Разработана версия последовательного HIPPI на скорость обмена 1,2 Гбод для коаксиального и оптоволоконного кабеля (до 10км; версия HIPPI-FC – fiber channel). Максимальное расстояние между станцией и переключателем составляет 25 м. Максимальное дистанция между станциями (станция-переключатель-станция) равно 50 м. Предельное число станций зависит от типа используемых переключателей. Переключатели могут взаимодействовать друг с другом (HIPPI-SC), обеспечивая информационный обмен между станциями. Пример топологии сети hippi представлен на Рисунок 4.1.7.1.
Пример реализации алгоритма Хафмана
Рисунок 2.6.5.1 Пример реализации алгоритма Хафмана
На следующем шаге наименее вероятными сообщениями окажутся m(1) и m(2). Кодовые слова на полученном дереве считываются справа налево. Алгоритм выдает оптимальный код (минимальная избыточность).
При использовании кодирования по схеме Хафмана надо вместе с закодированным текстом передать соответствующий алфавит. При передаче больших фрагментов избыточность, сопряженная с этим не может быть значительной.
Возможно применение стандартных алфавитов (кодовых таблиц) для пересылки английского, русского, французского и т.д. текстов, программных текстов на С++, Паскале и т.д. Кодирование при этом не будет оптимальным, но исключается статистическая обработка пересылаемых фрагментов и отпадает необходимость пересылки кодовых таблиц.
Пример топологии сети hippi (П – переключатели, С – станции)
Рисунок 4.1.7.1. Пример топологии сети hippi (П – переключатели, С – станции)
HIPPI предполагает передачу данных по медному кабелю (или оптическому волокну) только в одном направлении по схеме связи точка-точка, но два канала HIPPI могут обеспечить и двунаправленный обмен данными. Передающий кабель может содержать 50/100 скрученных пар или соответствующее число оптических волокон. Длина пакета данных может варьироваться. Протокол HIPPI рассчитан на работу в реальном масштабе времени при суммарных длинах кабелей до десятков километров. Стандартный блок данных содержит 256 слов (1024 или 2048 байт). Для контроля корректности передачи предусмотрен контроль по четности для каждого байта на шине, кроме того, для каждого блока данных вычисляется “продольная” контрольная сумма (LLRC - length/longitudinal redundancy checkword). На Рисунок 4.1.7.2 показана схема передачи данных в рамках протокола HIPPI. На каждое соединение может быть передано любое число пакетов, пакет в свою очередь может содержать любое число блоков. Время между пакетами не регламентировано и может меняться, оно зависит от потока данных и протокола верхнего уровня.
Разные предупреждения
99 Разные предупреждения
Текст предупреждения включает в себя любую информацию, которая может быть представлена человеку-оператору или может быть занесена в дневник операций. Система, получающая это предупреждение, не должна предпринимать каких-либо действий автоматически.
Поле заголовка отклика WWW-Authenticate должно включаться в сообщения откликов со статусным кодом 401 (Unauthorized). Значение поля содержит, по крайней мере, одно требование, которое указывает на схему идентификации и параметры, применимые для Request-URI.
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
Процесс авторизации доступа HTTP описан в разделе 10. Агенты пользователя должны проявлять особую тщательность при разборе значения поля WWW-Authenticate, если оно содержит более одного требования, или если прислан более чем одно поле заголовка WWW-Authenticate, так как содержимое требования может само содержать список параметров идентификации, элементы которого разделены запятыми.
Этот раздел предназначен для того, чтобы проинформировать разработчиков приложений, поставщиков информации и пользователей об ограничениях безопасности в HTTP/1.1, как это описано в данном документе. Обсуждение не включает определенные решения данных проблем, но рассматриваются некоторые предложения, которые могут уменьшить риск.
Базовая схема идентификации не предоставляет безопасного метода идентификации пользователя, не обеспечивает она и какох-либо средств защиты объектов, которые передаются открытым текстом по используемым физическим сетям. HTTP не мешает внедрению дополнительных схем идентификации и механизмов шифрования или других мер, улучшающих безопасность системы (например, SSL или одноразовых паролей).
Наиболее серьезным дефектом базового механизма идентификации является то, что пароль пользователя передается по сети в незашифрованном виде.
Так как базовая идентификация предусматривает пересылку паролей открытым текстом, она никогда не должна использоваться (без улучшения) для работы с конфиденциальной информацией.
Обычным назначением базовой идентификации является создание информационной (справочной) среды, которая требует от пользователя его имени и пароля, например, для сбора точной статистики использования ресурсов сервера. При таком использовании предполагается, что не существует никакой опасности даже в случае неавторизованного доступа к защищенному документу. Это правильно, если сервер генерирует сам имя и пароль пользователя и не позволяет ему выбрать себе пароль самостоятельно. Опасность возникает, когда наивные пользователи часто используют один и тот же пароль, чтобы избежать необходимости внедрения многопарольной системы защиты.
Если сервер позволяет пользователям выбрать их собственный пароль, тогда возникает опасность несанкционированного доступа к документам на сервере и доступа ко всем аккаунтам пользователей, которые выбрали собственные пароли. Если пользователям разрешен выбор собственных паролей, то это означает, что сервер должен держать файлы, содержащие пароли (предположительно в зашифрованном виде). Многие из этих паролей могут принадлежать удаленным пользователям. Собственник или администратор такой системы может помимо своей воли оказаться ответственным за нарушения безопасности сохранения информации.
Базовая идентификация уязвима также для атак поддельных серверов. Когда пользователь связывается с ЭВМ, содержащей информацию, защищенную с использованием базовой системой идентификации, может так получиться, что в действительности он соединяется с сервером-злоумышленником, целью которого является получение идентификационных параметров пользователя (например, имени и пароля). Этот тип атак не возможен при использовании идентификации с помощью дайджестов [32]. Разработчики серверов должны учитывать возможности такого рода атак со стороны ложных серверов или CGI-скриптов. В частности, очень опасно для сервера просто прерывать связь со шлюзом, так как этот шлюз может тогда использовать механизм постоянного соединения для выполнения нескольких процедур с клиентом, исполняя роль исходного сервера, так что это незаметно клиенту.
14.2. Предложение выбора схемы идентификации
Сервер HTTP/1. 1 может прислать несколько требований с откликом 401 (Authenticate) и каждое требование может использовать разную схему. Порядок присылки требований соответствует шкале предпочтений сервера. Сервер должен упорядочит требования так, чтобы наиболее безопасная схема предлагалась первой. Агент пользователя должен выбрать первую понятную ему схему.
Когда сервер предлагает выбор схемы идентификации, используя заголовок WWW-Authenticate, безопасность может быть нарушена только за счет того, что злонамеренный пользователь может перехватить набор требований и попытаться идентифицировать себя, используя саму слабую схему идентификации. Таким образом, упорядочение служит более для защиты идентификационных параметров пользователя, чем для защиты информации на сервере.
Возможна атака MITM (man-in-the-middle – "человек в середине"), которая заключается в добавлении слабой схемы идентификации к списку выбора в надежде на то, что клиент выберет именно ее и раскроет свой пароль. По этой причине клиент должен всегда использовать наиболее строгую схему идентификации из предлагаемого списка.
Еще эффективнее может быть MITM-атака, при которой удаляется весь список предлагаемых схем идентификации, и вставляется вызов, требующий базовой схемы идентификации. По этой причине агенты пользователя, обеспокоенные таким видом атак, могут запомнить самую строгую схему идентификации, которая когда-либо запрашивалась данным сервером, и выдавать предупреждение, которое потребует подтверждения пользователя при использовании более слабой схемы идентификации. Особенно хитроумный способ реализации MITM-атаки является предложение услуг "свободного" кэширования для доверчивых пользователей.
14.3. Злоупотребление служебными (Log) записями сервера
Сервер должен оберегать информацию о запросах пользователя, о характере его интересов (такая информация доступна в дневнике операций сервера). Эта информация является, очевидно, конфиденциальной по своей природе и работа с ней во многих странах ограничена законом.
Люди, использующие протокол HTTP для получения данных, являются ответственными за то, чтобы эта информация не распространялась без разрешения лиц, кого эта информация касается.
14.4. Передача конфиденциальной информации
Подобно любому общему протоколу передачи данных, HTTP не может регулировать содержимое передаваемых данных, не существует методов определения степени конфиденциальности конкретного фрагмента данных в пределах контекста запроса. Следовательно, приложения должны предоставлять как можно больше контроля провайдеру информации. Четыре поля заголовка представляют интерес с этой точки зрения: Server, Via, Referer и From. Раскрытие версии программного обеспечения сервера может привести к большей уязвимости машины сервера к атакам на программы с известными слабостями. Разработчики должны сделать поле заголовка Server конфигурируемой опцией. Прокси, которые служат в качестве сетевого firewall, должны предпринимать специальные предосторожности в отношении передачи информации заголовков, идентифицирующей ЭВМ, за пределы firewall. В частности они должны удалять или замещать любые поля Via, созданные в пределах firewall. Хотя поле Referer может быть очень полезным, его мощь может быть использована во вред, если данные о пользователе не отделены от другой информации, содержащейся в этом поле. Даже когда персональная информация удалена, поле Referer может указывать на URI частных документов, чья публикация нежелательна. Информация, посланная в поле From, может вступать в конфликт с интересами конфиденциальности пользователя или с политикой безопасности его домена, и, следовательно, она не должна пересылаться и модифицироваться без прямого разрешения пользователя. Пользователь должен быть способен установить содержимое этого поля, в противном случае оно будет установлено равным значению по умолчанию. Мы предлагаем, хотя и не требуем, чтобы предоставлялся удобный интерфейс для пользователя, который позволяет активировать и дезактивировать посылку информации полей From и Referer.
14.5. Атаки, основанные на именах файлов и проходов
Реализации исходных серверов HTTP должна быть тщательной, чтобы ограничить список присылаемых HTTP документов теми, которые определены для этого администратором сервера. Если сервер HTTP транслирует HTTP URI непосредственно в запросы к файловой системе, сервер должен следить за тем, чтобы не пересылать файлы клиентам HTTP, для этого не предназначенные. Например, UNIX, Microsoft Windows и другие операционные системы используют ".." как компоненту прохода, чтобы указать уровень каталога выше текущего. В такой системе сервер HTTP должен запретить любую подобную в Request-URI, если она позволяет доступ к ресурсу за пределами того, что предполагалось. Аналогично, файлы, предназначенные только для внутреннего использования сервером (такие как файлы управления доступом, конфигурационные файлы и коды скриптов) должны быть защищены от несанкционированного доступа, так как они могут содержать конфиденциальную информацию. Практика показала, что даже незначительные ошибки в реализации сервера HTTP могут привести к рискам безопасности.
14.6. Персональная информация
Клиентам HTTP небезразличнен доступ к некоторым данным (например, к имени пользователя, IP-адресу, почтовому адресу, паролю, ключу шифрования и т.д.). Система должна быть тщательно сконструирована, чтобы предотвратить непреднамеренную утечку информации через протокол HTTP. Мы настоятельно рекомендуем, чтобы был создан удобный интерфейс для обеспечения пользователя возможностями управления распространением такой информации.
14.7. Аспекты конфиденциальности, связанные с заголовками Accept
Заголовок запроса Accept может раскрыть информацию о пользователе всем серверам, к которым имеется доступ. В частности, заголовок Accept-Language может раскрыть информацию, которую пользователь, возможно, рассматривает как конфиденциальную. Так, например, понимание определенного языка часто строго коррелируется с принадлежностью к определенной этнической группе. Агентам пользователя, которые предлагают возможность конфигурирования содержимого заголовка Accept-Language, настоятельно рекомендуется посылать сообщение пользователю о том, что в результате может быть потеряна конфиденциальность определенных данных.
Подходом, который ограничивает потерю конфиденциальности для агента пользователя, может быть отказ от посылки заголовков Accept-Language по умолчанию. Предполагается при этом каждый раз консультироваться с пользователем относительно возможности посылки этих данных серверу. Пользователь будет принимать решение о посылке Accept-Language, лишь убедившись на основании содержимого заголовка отклика Vary в том, что такая посылка существенно улучшит качество обслуживания.
Для многих пользователей, которые размещены не за прокси, сетевой адрес работающего агента пользователя может также использоваться как его идентификатор. В среде, где прокси используются для повышения уровня конфиденциальности, агенты пользователя должны быть достаточно консервативны в предоставлении опционного конфигурирования заголовков доступа конечным пользователям. В качестве крайней меры обеспечения защиты прокси могут фильтровать заголовки доступа для передаваемых запросов. Главной целью агентов пользователя, которые предоставляют высокий уровень конфигурационных возможностей, должно быть предупреждение пользователя о возможной потере конфиденциальности.
14.8. Фальсификация DNS
Клиенты, интенсивно использующие HTTP обмен со службой имен домена (Domain Name Service), обычно предрасположены к атакам, базирующимся на преднамеренном некорректном соответствии IP адресов и DNS имен. Клиенты должны быть осторожны относительно предположений, связанных с ассоциаций IP адресов и DNS имен.
В частности, клиенту HTTP следует полагаться на его сервер имен для подтверждения соответствия IP адресов и DNS имен, а не слепо кэшировать результаты предшествующих запросов. Многие платформы могут кэшировать такие запросы локально и это надо использовать, конфигурируя их соответствующим образом. Такие запросы должны кэшироваться, однако только на период, пока не истекло время жизни этой информации.
Если клиенты HTTP кэшируют результат DNS-запроса для улучшения рабочих характеристик, они должны отслеживать пригодность этих данных с учетом времени жизни, объявляемого DNS-сервером.
Если клиенты HTTP не следуют этому правилу, они могут быть мистифицированы, когда изменится IP-адрес доступного ранее сервера. Так как смена адресов в сетях будет в ближайшее время активно развиваться (Ipv6 !), такого рода атаки становятся все более вероятными.
Данное требование улучшает работу клиентов, в том числе с серверами, имеющими идентичные имена.
14.9. Заголовки Location и мистификация
Если один сервер поддерживает несколько организаций, которые не доверяют друг другу, тогда он должен проверять значения заголовков Location и Content-Location в откликах, которые формируются под управлением этих организаций. Это следует делать, чтобы быть уверенным, что они не пытаются провести какие-либо операции над ресурсами, доступ к которым для них ограничен.
16. Библиография
| [1] | Alvestrand, H., "Tags for the identification of languages", RFC 1766, UNINETT, March 1995. |
| [2] | Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D., and B. Alberti. "The Internet Gopher Protocol: (a distributed document search and retrieval protocol)", RFC 1436, University of Minnesota, March 1993 |
| [3] | Berners-Lee, T., "Universal Resource Identifiers in WWW", A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", RFC 1630, CERN, June 1994 |
| [4] | Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, December 1994 |
| [5] | Berners-Lee, T., and D. Connolly, "HyperText Markup Language Specification - 2.0", RFC 1866, MIT/LCS, November 1995 |
| [6] | Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0.", RFC 1945 MIT/LCS, UC Irvine, May 1996 |
| [7] | Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996. |
| [8] | Braden, R., "Requirements for Internet hosts - application and support", STD3, RFC 1123, IETF, October 1989 |
| [9] | Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982 |
| [10] | Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., Sui, J., and M. Grinbaum. "WAIS Interface Protocol Prototype Functional Specification", (v1.5), Thinking Machines Corporation, April 1990 |
| [11] | Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC Irvine, June 1995 |
| [12] | Horton, M., and R. Adams. "Standard for interchange of USENET messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic Studies, December 1987 |
| [13] | Kantor, B., and P. Lapsley. "Network News Transfer Protocol." A Proposed Standard for the Stream-Based Transmission of News", RFC 977, UC San Diego, UC Berkeley, February 1986 |
| [14] | Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, University of Tennessee, November 1996 |
| [15] | Nebel, E., and L. Masinter. "Form-based File Upload in HTML", RFC 1867, Xerox Corporation, November 1995. |
| [16] | Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/ISI, August 1982 |
| [17] | Postel, J., "Media Type Registration Procedure", RFC 2048, USC/ISI, November 1996 |
| [18] | Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, USC/ISI, October 1985 |
| [19] | Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC1700, USC/ISI, October 1994 |
| [20] | Sollins, K., and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation, December 1994 |
| [21] | US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986 |
| [22] | ISO-8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets |
| Part 1: Latin alphabet No. 1, ISO 8859-1:1987 | |
| Part 2: Latin alphabet No. 2, ISO 8859-2, 1987 | |
| Part 3: Latin alphabet No. 3, ISO 8859-3, 1988 | |
| Part 4: Latin alphabet No. 4, ISO 8859-4, 1988 | |
| Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988 | |
| Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987 | |
| Part 7: Latin/Greek alphabet, ISO 8859-7, 1987 | |
| Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988 | |
| Part 9: Latin alphabet No. 5, ISO 8859-9, 1990 | |
| [23] | Meyers, J., and M. Rose "The Content-MD5 Header Field", RFC1864, Carnegie Mellon, Dover Beach Consulting, October, 1995 |
| [24] | Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC 1900, IAB, February 1996. |
| [25] | Deutsch, P., "GZIP file format specification version 4.3." RFC1952, Aladdin Enterprises, May 1996 |
| [26] | Venkata N. Padmanabhan and Jeffrey C. Mogul. Improving HTTP Latency. Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec. 1995. Slightly revised version of paper in Proc. 2nd International WWW Conf. '94: Mosaic and the Web, Oct. 1994, which is available at http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/ mogul/HTTPLatency.html. |
| [27] | Joe Touch, John Heidemann, and Katia Obraczka, "Analysis of HTTP Performance", , USC/Information Sciences Institute, June 1996 |
| [28] | Mills, D., "Network Time Protocol, Version 3, Specification, Implementation and Analysis", RFC 1305, University of Delaware, March 1992 |
| [29] | Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3." RFC 1951, Aladdin Enterprises, May 1996 |
| [30] | Spero, S., "Analysis of HTTP Performance Problems" . |
| [31] | Deutsch, P., and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, Aladdin Enterprises, Info-ZIP, May 1996 |
| [32] | Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, January 1997 |
/p> 16. Приложения
16.1. Интерентовский тип среды "message/http"
В дополнение к определению протокола HTTP/1.1, данный документ является спецификацией для типов среды Интернет "message/http". Ниже приведенный список является официальным для IANA.
| Media Type name: | message |
| Media subtype name: | http |
| Required parameters: | none |
| Optional parameters: | version, msgtype |
msgtype: Тип сообщения -- "запроса" или "отклика". Если отсутствует, тип может быть определен по первой строке тела сообщения.
Соображения кодирования: разрешено только "7bit", "8bit" или "binary" (двоичное).
16.2. Тип среды Интернет "multipart/byteranges"
Когда сообщение HTTP содержит несколько фрагментов (ranges) (например, отклик на запрос нескольких не перекрывающихся фрагментов), они пересылаются как многофрагментное сообщение MIME. Тип среды multipart для этих целей носит название "multipart/byteranges".
Тип среды multipart/byteranges содержит в себе две или более части, каждая из которых со своими полями Content-Type и Content-Range. Отдельные части разделяются с использованием пограничного параметра MIME.
| Media Type name: | multipart |
| Media subtype name: | byteranges |
| Required parameters: | boundary |
| Optional parameters: | none |
Например:
HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 500-999/8000
...первый фрагмент ...
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 7000-7999/8000
...второй фрагмент...
--THIS_STRING_SEPARATES--
16.3. Толерантные приложения
Хотя этот документ специфицирует требования к генерации HTTP/1.1 сообщений, не все приложения будут корректны. Мы, следовательно, рекомендуем, чтобы рабочие приложения были толерантны (терпимы) к некоторым отклонениям от требований, при условии, что эти отклонения можно однозначно интерпретировать. Клиенту следует быть толерантным при разборе Status-Line, а серверу – при разборе Request-Line. В частности, им следует воспринимать любое число символов SP или HT между полями, хотя требуется только один пробел (SP). Терминатором строки полей заголовков сообщения является CRLF. Однако рекомендуется, чтобы приложение при разборе таких заголовков распознавало в качестве терминатора строки одиночный символ LF и игнорировала предыдущий символ CR. Символьный набор тела объекта должен быть снабжен меткой. Метка не нужна только для набора US-ASCII или ISO-8859-1. Правила разбора и кодирования дат и пр. включают в себя предположение, что HTTP/1.1 клиенты и кэши должны предполагать, что даты, следующие документу RFC-850 и относящиеся ко времени 50 лет в будущем, на самом деле относятся к прошлому (это помогает решить проблему "2000-го года").
Приложение HTTP/1.1 может внутри представлять время истечения годности раньше, чем истинное значение, но не должно представлять его позднее истинного значения.
Все вычисления, относящиеся ко времени пригодности должны выполняться в шкале GMT (по Гринвичу). Местные временные зоны не должны оказывать влияния на вычисления и сравнение возраста и времени пригодности.
Если заголовок HTTP несет в себе некорректное значение даты с временной зоной отличной от GMT, значение должно быть преобразовано в GMT.
16.4. Различие между объектами HTTP и MIME
HTTP/1.1 использует много конструкций, определенных для электронной почты Интернет (RFC 822) и MIME (Multipurpose Internet Mail Extensions), для обеспечения пересылки объектов в различных представлениях. MIME [7] обслуживает электронную почту, а HTTP имеет лишь ряд черт, которые отличают его от MIME.
Эти отличия тщательно подобраны, чтобы оптимизировать работу в условиях двоичных соединений, с тем чтобы достичь большей свободы в использовании новых типов сред. Прокси и шлюзы должны по возможности исключать такие отличия и обеспечивать соответствующие преобразования там, где это нужно.
16.4.1. Преобразование к канонической форме
MIME требует, чтобы почтовый объект Интернет перед посылкой был преобразован в каноническую форму. Раздел 2.7.1 описывает формы, допустимые для подтипов типа среды "text" при пересылке с использованием HTTP. MIME требует, чтобы содержимое типа "text" представляло разрывы строк в виде последовательности символов CRLF и запрещает использование CR или LF отдельно. Для обозначения разрыва строки HTTP позволяет использовать CRLF, одиночный CR и одиночный LF. Всюду где возможно, прокси и шлюзы между средами HTTP и MIME должны преобразовать все разрывы строк для текстовых типов среды, как это описано в разделе 2.7.1. Заметьте однако, что это может вызвать сложности в присутствии кодирования содержимого, а также вследствие того, что HTTP допускает применение символьных наборов, которые не используют октеты 13 и 10 для представления CR и LF, так как для этих целей здесь служат многобайтовые последовательности.
16.4.2. Преобразование форматов даты
Для того чтобы упростить сравнение, HTTP/1.1 использует ограниченный набор форматов даты (раздел 2.3.1). Прокси и шлюзы должны позаботиться о преобразовании полей заголовков даты в один из допустимых форматов всякий раз, когда это необходимо (при получении данных от других протоколов).
16.4.3. Введение кодирования содержимого
MIME не содержит какого-либо эквивалента полю заголовка Content-Encoding HTTP/1.1. Так как это поле работает как модификатор типа среды, прокси и шлюзы между HTTP и MIME протоколами должны или изменить значение поля заголовка Content-Type или декодировать тело объекта, прежде чем переадресовывать сообщение. Некоторые экспериментальные приложения Content-Type для почты Интернет используют параметр типа среды ";conversions=" для выполнения операции, аналогичной Content-Encoding.
Однако, этот параметр не является частью MIME.
16.4.4. No Content-Transfer-Encoding
HTTP не использует поле MIME CTE (Content-Transfer-Encoding). Прокси и шлюзы от MIME к HTTP должны удалять любую не идентичность CTE ("quoted-printable" или "base64") кодирования, прежде чем доставлять сообщение-отклик клиенту HTTP.
Прокси и шлюзы от HTTP к MIME ответственны за то, чтобы сообщения имели корректные форматы и кодировки для безопасной транспортировки, (где безопасная транспортировка определяется ограничениями используемого протокола). Такие прокси и шлюзы должны помечать информацию согласно Content-Transfer-Encoding, поступая так, мы улучшаем вероятность безопасной транспортировки с использованием протокола места назначения.
16.4.5. Поля заголовка в многофрагментных телах
В MIME, большинство полей заголовка в многофрагментных частях игнорируются, если только имя поля не начинается с "Content-". В HTTP/1.1, многофрагментные части тела могут содержать любые поля заголовков HTTP, которые имеют смысл для этой части.
16.4.6. Введение транспортного кодирования
HTTP/1.1 вводит поле заголовка Transfer-Encoding (раздел 13.40). Прокси/шлюзы должны удалять любое транспортное кодирование перед переадресацией сообщения через протокол MIME.
Процесс декодирования транспортного кода (раздел 2.6) может быть представлен в виде псевдо-программы:
length := 0
read chunk-size, chunk-ext (if any) and CRLF
while (chunk-size > 0) {
read chunk-data and CRLF
append chunk-data to entity-body
length := length + chunk-size
read chunk-size and CRLF
}
read entity-header
while (entity-header not empty) {
append entity-header to existing header fields
read entity-header
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
16.4.7. MIME-Version
HTTP не является протоколом, совместимым с MIME (смотри приложение 16.4). Однако HTTP/1.1 сообщения могут включать поле общего заголовка MIME-Version, для того чтобы указать, какая версия протокола MIME была использована для конструирования сообщения.
Использование заголовка поля MIME- Version отмечает, сообщение полностью соответствует протоколу MIME. Прокси/шлюзы несут ответственность за полную совместимость (где возможно), когда осуществляется передача HTTP сообщений в среду MIME.
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
HTTP/1.1 использует по умолчанию версию MIME "1.0". Однако разбор сообщений HTTP/1.1 и семантика определяются данным документом, а не спецификацией MIME.
16.5. Изменения по отношению HTTP/1.0
Этот раздел обобщает основные отличия между версиями HTTP/1.0 и HTTP/1.1.
16.5.1. Изменения с целью упрощения распределенных WWW-сервером и экономии IP адресов
Требование того, чтобы клиенты и серверы воспринимали абсолютные URI (раздел 4.1.2) и поддерживали заголовки Host, откликались кодами ошибки при отсутствии заголовка Host (раздел 13.23) в запросе HTTP/1.1, являются наиболее важными изменениями, внесенными данной спецификацией.
Более старые HTTP/1.0 клиенты предполагают однозначное соответствие IP адресов и серверов. Изменения, описанные выше, позволяют Интернет поддерживать несколько WWW узлов с помощью одного IP-адреса. Высокая скорость роста WWW-сети, большое число уже существующих серверов делают крайне важным, чтобы реализации HTTP (включая усовершенствования существующих HTTP/1.0 приложений) корректно следовали перечисленным ниже требованиям:
Как клиент, так и сервер должны поддерживать заголовки запроса Host.
Заголовки Host необходимы в запросах HTTP/1.1.
Серверы должны откликаться кодом ошибки 400 (Bad Request), если запрос HTTP/1.1 не содержит заголовка Host.
Серверы должны воспринимать абсолютные URI.
16.6. Дополнительные функции
Это приложение документирует протокольные элементы, используемые некоторыми существующими реализациями HTTP, но не вполне корректно совместимыми с большинством HTTP/1.1 приложений.
16.6.1. Дополнительные методы запросов
16.6.1.1. Метод PATCH
Метод PATCH подобен PUT, за исключением того, что объект содержит список отличий между оригинальной версией ресурса, идентифицированного Request-URI, и желательной версией ресурса после операции PATCH.
Список отличий записывается в формате, определенном типом среды объекта (например, "application/diff"), и должен включать достаточную информацию, чтобы позволить серверу выполнить изменения по преобразованию ресурса из исходной версии в заказанную.
Если запрос проходит через кэш и Request-URI идентифицирует объект в кэше, этот объект должен быть удален из кэша. Отклики для этого метода не кэшируются.
Реальный метод определения того, как разместится скорректированный ресурс и что случится с его предшественником, определяется исключительно исходным сервером. Если оригинальная версия ресурса, который предполагается скорректировать, включает в себя поле заголовка Content-Version, объект запроса должен включать поле заголовка Derived-From, соответствующее значению оригинального поля заголовка Content-Version. Приложениям рекомендуется использовать эти поля для работы с версиями с целью разрешения соответствующих конфликтов. Запросы PATCH должны подчиняться требованиям к передаче сообщений, установленным в разделе 7.2. Кэши, которые реализуют PATCH, должны объявить кэшированные отклики недействительными, как это описано в разделе 12.10 для PUT.
16.6.1.2. Метод LINK
Метод LINK устанавливает один или более связей между ресурсами, идентифицированными Request-URI, и другими существующими ресурсами. Отличие между LINK и другими методами, допускающими установление связей между ресурсами, заключается в том, что метод LINK не позволяет послать в запросе любое тело сообщения и не вызывает непосредственно создания новых ресурсов. Если запрос проходит через кэш и Request-URI идентифицирует кэшированный объект, этот объект должен
быть удален из кэша. Отклики на этот метод не кэшируются. Кэши, которые реализуют LINK, должны объявить кэшированные отклики непригодными, как это определено в разделе 12.10 для PUT.
16.6.1.3. Метод UNLINK
Метод UNLINK удаляет одну или более связей между ресурсами, идентифицированными Request-URI. Эти связи могут быть установлены с использованием метода LINK или каким-либо другим методом, поддерживающим заголовок Link.
Удаление связи с ресурсом не подразумевает, что ресурс перестает существовать или становится недоступным. Если запрос проходит через кэш и Request-URI идентифицирует кэшированный объект, этот объект должен быть удален из кэша. Отклики на этот метод не кэшируются. Кэши, которые реализуют UNLINK, должны объявить кэшированные отклики непригодными, как это определено в разделе 12.10 для PUT.
16.6.2. Определения дополнительных полей заголовка
16.6.2.1. Поле Alternates
Поле заголовка отклика Alternates было предложено в качестве средства исходного сервера для информирования клиента о других доступных представлениях запрошенного ресурса. При этом выдается информация об их специфических атрибутах, все это образует более надежное основание агенту пользователя для выбора представления, которое лучше соответствует желаниям пользователя (описано как согласование под управлением агента пользователя в разделе 11). Поле заголовка Alternates является ортогональным по отношению к полю заголовка Vary, вместе с тем они могут сосуществовать в сообщении без последствий для интерпретации отклика или доступных представлений. Ожидается, что поле Alternates предоставит заметное улучшение по сравнению с согласованием под управлением сервера, предоставляемым полем Vary для ресурсов, которые варьируются в общих пределах подобно типу и языку. Поле заголовка Alternates будет определено в будущей спецификации.
16.6.2.2. Поле Content-Version
Поле заголовка объекта Content-Version определяет метку версии, ассоциированную с отображением объекта. Вместе с полем Derived-From, 16.6.2.3, это позволяет группе людей вести разработку в интерактивном режиме.
Content-Version = "Content-Version" ":" quoted-string.
Примеры использования поля Content-Version:
Content-Version: "2.1.2"
Content-Version: "Fred 19950116-12:26:48"
Content-Version: "2.5a4-omega7"
16.6.2.3. Поле Derived-From
Поле заголовка объекта Derived-From может использоваться для индикации метки версии ресурса, из которого был извлечен объект до модификации, выполненной отправителем.
Это поле используется для того, чтобы помочь управлять процессом эволюции ресурса, в частности, когда изменения выполняются в параллель многими субъектами.
Derived-From = "Derived-From" ":" quoted-string.
Пример использования поля:
Derived-From: "2.1.1".
Поле Derived-From необходимо для запросов PUT и PATCH, если посланный объект был перед этим извлечен из того же URI и заголовок Content-Version был включен в объект, когда он последний раз извлекался.
16.6.2.4. Поле Link
Поле заголовка объекта Link предоставляет средства для описания взаимоотношений между ресурсами. Объект может включать много значений поля Link. Связи на уровне метаинформации обычно указывают на отношения типа структуры иерархии и пути прохода. Поле Link семантически эквивалентно элементу в HTML[5].
| Link | = "Link" ":"#("" *(";" link-param) |
| link-param | = (("rel" "=" relationship ) |
| | ("rev" "=" relationship) | |
| | ( "title" "=" quoted-string ) | |
| | ( "anchor" "=" URI ) | |
| | (link-extension )) | |
| link-extension | = token ["=" (token | quoted-string )] |
| relationship | = sgml-name |
| | ( sgml-name *( SP sgml-name) ) | |
| sgml-name | = ALPHA *( ALPHA | DIGIT | "." | "-") |
Link: ; rel="Previous"
Link: ; rev="Made"; title="Tim Berners-Lee"
Первый пример указывает, что глава 2 предшествует данному ресурсу с точки зрения логического прохода. Второй указывает, что лицо, ответственное за данный ресурс, имеет приведенный адрес электронной почты.
16.6.2.5. Поле URI
Поле заголовка URI использовалось в прошлых версиях данной спецификации как комбинация существующих полей заголовка Location, Content-Location и Vary. Его первоначальной целью являлось включение списка дополнительных URI для ресурса, включая имена и положение зеркал. Однако, стало ясно, что комбинация многих различных функций в пределах одного поля мешает эффективной их реализации. Более того, мы полагаем, что идентификация имени положения зеркал лучше осуществлять через поле заголовка Link. Поле заголовка URI было признано менее удобным, чем эти поля.
URI-header = "URI" ":" 1#( "" )
16.7. Совместимость с предыдущими версиями
HTTP/1.1 был специально спроектирован так, чтобы обеспечить совместимость с предыдущими версиями. Следует заметить, что на фазе разработки этой спецификации мы предполагали, что коммерческие HTTP/1.1 серверы будут следовать следующим правилам:
распознают формат Request-Line для запросов HTTP/0.9, 1.0 и 1.1;
воспринимают любой корректный запрос в формате HTTP/0.9, 1.0 или 1.1;
корректно откликаются сообщениями с той же версией, что использовал клиент.
Мы также ожидаем, что клиенты HTTP/1.1:
распознают формат откликов Status-Line для HTTP/1.0 и 1.1;
воспринимают любой корректный отклик в формате HTTP/0.9, 1.0 или 1.1.
Для большинства реализаций HTTP/1.0, каждое соединение устанавливается клиентом до посылки запроса и закрывается сервером после посылки отклика. Некоторые реализации используют версию Keep-Alive постоянного соединения, описанную в разделе 16.7.1.1.
16.7.1. Совместимость с постоянными соединениями HTTP/1.0
Некоторые клиенты и серверы могут пожелать быть совместимыми с некоторыми предшествующими реализациями HTTP/1.0 постоянных соединений клиента и сервера. Постоянные соединения в HTTP/1.0 должны согласовываться в явном виде, так как это не является вариантом по умолчанию. Экспериментальные реализации постоянных соединений в HTTP/1.0 не лишены ошибок. Проблема была в том, что некоторые существующие клиенты 1.0 могут посылать Keep-Alive прокси-серверу, которые не понимает Connection, и ошибочно переадресует его ближайшему серверу. Последний установит соединение Keep-Alive, что приведет к повисанию системы, так как прокси будет ждать close для отклика. В результате клиентам HTTP/1.0 должно быть запрещено использование Keep-Alive, когда они работают с прокси. Однако, взаимодействие с прокси является наиболее важным использованием постоянных соединений, по этой причине подобный запрет является не приемлемым. Следовательно, нам нужен какой-то другой механизм для индикации намерения установить постоянное соединение. Этот механизм должен быть безопасным даже при взаимодействии со старыми прокси, которые игнорируют Connection. Постоянные соединения для сообщений HTTP/1.1 работают по умолчанию; мы вводим новое ключевое слово (Connection: close) для декларации непостоянства соединения. Ниже описана оригинальная форма постоянных соединений для HTTP/1.0. Когда HTTP клиент соединяется с исходным сервером, он может послать лексему соединения Keep-Alive в дополнение к лексеме соединения Persist:
Connection: Keep-Alive.
Сервер HTTP/1.0 откликнется лексемой соединения Keep-Alive и клиент сможет установить постоянное (или Keep-Alive) соединение с HTTP/1.0. Сервер HTTP/1.1 может также установить постоянное соединение с клиентом HTTP/1.0 по получении лексемы соединения Keep-Alive. Однако, постоянное соединение с клиентом HTTP/1.0 не может быть использовано для по-фрагментного кодирования и, следовательно, должно использовать Content-Length для пометки конца каждого сообщения. Клиент не должен посылать лексему соединения Keep-Alive прокси-серверу, так как прокси-сервера HTTP/1.0 не следуют правилам HTTP/1.1 при разборе поля заголовка Connection.
16.7.1.1. Заголовок Keep-Alive
Когда лексема соединения Keep-Alive передана в рамках запроса или отклика, поле заголовка Keep-Alive может также присутствовать. Поле заголовка Keep-Alive имеет следующую форму:
Keep-Alive-header = "Keep-Alive" ":" 0# keepalive-param
keepalive-param = param-name "=" value.
Заголовок Keep-Alive является опционным и используется, если передается параметр. HTTP/1.1 не определяет каких-либо параметров. Если посылается заголовок Keep-Alive, должна быть передана соответствующая лексема соединения. Заголовок Keep-Alive без лексемы соединения должен игнорироваться.
Response is stale (отклик устарел)
10 Response is stale (отклик устарел)
Должно включаться всякий раз, когда присылаемый отклик является устаревшим. Кэш может добавить это предупреждение к любому отклику, но не может удалить его до тех пор, пока не будет установлено, что отклик является свежим.
Revalidation failed (перепроверка пригодности неудачна)
11 Revalidation failed (перепроверка пригодности неудачна)
Должно включаться, если кэш присылает устаревший отклик, потому что попытка перепроверить его пригодность не удалась, из-за невозможности достичь сервера. Кэш может добавить это предупреждение к любому отклику, но никогда не может удалить его до тех пор, пока не будет успешно проведена перепроверка пригодности отклика.
Символьный набор HTML
10.19 Символьный набор HTML
|
Кодовое представление |
Символ |
Описание |
| � -  | Не используется | |
| 	 | Символ горизонтальной табуляции | |
| 
 | Перевод строки | |
| | Возврат каретки | |
|  -  | Не используется | |
|   | Пробел | |
| ! | ! | Восклицательный знак |
| " | " | Кавычки |
| # | Знак числа () | |
| $ | $ | Знак доллара |
| % | % | Знак процента |
| & | & | Ampersand |
| ' | ' | Апостроф |
| ( | ( | Левая скобка |
| ) | ) | Правая скобка |
| * | * | Звездочка |
| + | + | Знак плюс |
| , | , | запятая |
| - | - | Дефис |
| . | . | Точка (полная остановка) |
| / | / | Косая черта (slash) |
| 0 - 9 | 0-9 | Цифры 0-9 |
| : | : | Двоеточие |
| ; | ; | Точка с запятой |
| < | < | Знак меньше чем |
| = | = | Знак равенства |
| > | > | Знак больше чем |
| ? | ? | Знак вопроса |
| @ | @ | Символ @ |
| A - Z | A-Z | Буквы A-Z |
| [ | [ | Левая квадратная скобка |
| \ | \ | Обратная косая черта (backslash) |
| ] | ] | Правая квадратная скобка |
| ^ | ^ | Знак вставки (^ caret) |
| _ | _ | Горизонтальная черта (underscore) |
| ` | Ударение | |
| a - z | a-z | Буквы a-z |
| { | { | Левая фигурная скобка |
| | | | | Вертикальная черта |
| } | } | Правая фигурная скобка |
| ~ | ~ | Тильда (~) |
|  - Ÿ | Не используется | |
|   | Неразрывный пробел | |
| ¡ | ? | Инвертированный восклицательный знак |
| ¢ | ? | Знак центов |
| £ | ? | Знак фунтов стерлингов |
| ¤ | ¤ | Обобщенный знак валюты |
| ¥ | ? | Знак иены |
| ¦ | ¦ | Разорванный знак вертикальной черты |
| § | § | Знак раздела (Section sign) |
| ¨ | ? | Умляут (горизонтальное двоеточие над буквой) |
| © | © | Знак авторского права (Copyright) |
| ª | ? | Feminine ordinal |
| « | « | Левая угловая кавычка (guillemotleft) |
| ¬ | ¬ | Знак отрицания (Not sign) |
| ­ | | Мягкий дефис (Soft hyphen) |
| ® | ® | Зарегистрированная торговая марка |
| ¯ | ? | Macron accent |
| ° | ° | Знак градуса (Degree sign) |
| ± | ± | Знак плюс или минус (± ) |
| ² | ? | Верхний индекс 2 (Superscript two) |
| ³ | ? | Верхний индекс 3 (Superscript three) |
| ´ | ? | Знак ударения (Acute accent) |
| µ | µ | Знак долготы над гласным (горизонтальная черта - Micro sign) |
| ¶ | ¶ | Знак параграфа |
| · | · | Центральная точка |
| ¸ | ? | Орфографический знак седиль (Cedilla) |
| ¹ | ? | Верхний индекс 1 (Superscript one) |
| º | ? | Masculine ordinal |
| » | » | Правая угловая кавычка (guillemotright) |
| ¼ | ? | Дробь ј |
| ½ | ? | Дробь 1/2 |
| ¾ | ? | Дробь ѕ |
| ¿ | ? | Инвертированный знак вопроса |
| À | A | Прописное A, grave accent |
| Á | A | Прописное A, acute accent |
| Â | A | Прописное A, circumflex accent |
| Ã | A | Прописное A, tilde |
| Ä | A | Прописное A, dieresis or umlaut mark |
| Å | A | Прописное A, ring |
| Æ | ? | Прописное AE dipthong (ligature) |
| Ç | C | Прописное C, cedilla |
| È | E | Прописное E, grave accent |
| É | E | Прописное E, acute accent |
| Ê | E | Прописное E, circumflex accent |
| Ë | E | Прописное E, dieresis or umlaut mark |
| Ì | I | Прописное I, grave accent |
| Í | I | Прописное I, acute accent |
| Î | I | Прописное I, circumflex accent |
| Ï | I | Прописное I, dieresis or umlaut mark |
| Ð | ? | Прописное Eth, исландское |
| Ñ | N | Прописное N, tilde |
| Ò | O | Прописное O, grave accent |
| Ó | O | Прописное O, acute accent |
| Ô | O | Прописное O, circumflex accent |
| Õ | O | Прописное O, tilde |
| Ö | O | Прописное O, dieresis or umlaut mark |
| × | ? | Знак умножения |
| Ø | O | Прописное O, slash |
| Ù | U | Прописное U, grave accent |
| Ú | U | Прописное U, acute accent |
| Û | U | Прописное U, circumflex accent |
| Ü | U | Прописное U, dieresis or umlaut mark |
| Ý | Y | Прописное Y, acute accent |
| Þ | ? | Прописное THORN, Icelandic |
| ß | ? | Строчное sharp s, German (sz ligature) |
| à | a | Строчное a, grave accent |
| á | a | Строчное a, acute accent |
| â | a | Строчное a, circumflex accent |
| ã | a | Строчное a, tilde |
| ä | a | Строчное a, dieresis or umlaut mark |
| å | a | Строчное a, ring |
| æ | ? | Строчный дифтонг ae (ligature) |
| ç | c | Строчное c, cedilla |
| è | e | Строчное e, grave accent |
| é | e | Строчное e, acute accent |
| ê | e | Строчное e, circumflex accent |
| ë | e | Строчное e, dieresis or umlaut mark |
| ì | i | Строчное i, grave accent |
| í | i | Строчное i, acute accent |
| î | i | Строчное i, circumflex accent |
| ï | i | Строчное i, dieresis or umlaut mark |
| ð | ? | Строчное eth, Icelandic |
| ñ | n | Строчное n, tilde |
| ò | o | Строчное o, grave accent |
| ó | o | Строчное o, acute accent |
| ô | o | Строчное o, circumflex accent |
| õ | o | Строчное o, tilde |
| ö | o | Строчное o, dieresis or umlaut mark |
| ÷ | ? | Строчное ion sign |
| ø | o | Строчное o, slash |
| ù | u | Строчное u, grave accent |
| ú | u | Строчное u, acute accent |
| û | u | Строчное u, circumflex accent |
| ü | u | Строчное u, dieresis or umlaut mark |
| ý | y | Строчное y, acute accent |
| þ | ? | Строчное thorn, исландское |
| ÿ | y | Строчное y с умляутом (dieresis or umlaut mark) |
/p> <!-- Набор символьных объектов. Типичное обращение:
<!ENTITY % HTMLlat1 PUBLIC "-//W3C//ENTITIES Latin 1//EN//HTML">
%HTMLlat1; -->
| Описание | Название символа | Уникод | Название набора |
| <!ENTITY nbsp CDATA " " > | Неразрывный пробел | U+00A0 | ISOnum |
| <!ENTITY iexcl CDATA "¡" > | Инвертированный ! | U+00A1 | ISOnum |
| <!ENTITY cent CDATA "¢" > | Знак цента | U+00A2 | ISOnum |
| <!ENTITY pound CDATA "£" > | Знак фунта | U+00A3 | ISOnum |
| <!ENTITY curren CDATA "¤" > | Знак валюты | U+00A4 | ISOnum |
| <!ENTITY yen CDATA "¥" > | Знак иены | U+00A5 | ISOnum |
| <!ENTITY brvbar CDATA "¦" > | Разорванная вертикальная черта | U+00A6 | ISOnum |
| <!ENTITY sect CDATA "§" > | Знак секции | U+00A7 | ISOnum |
| <!ENTITY uml CDATA "¨" > | Диэреза = двоеточие над гласной | U+00A8 | ISOdia |
| <!ENTITY copy CDATA "©" > | Знак авторского права | U+00A9 | ISOnum |
| <!ENTITY ordf CDATA "ª" > | Указатель женского начала | U+00AA | ISOnum |
| <!ENTITY laquo CDATA "«" > | Левая двойная угловая кавычка | U+00AB | ISOnum |
| <!ENTITY not CDATA “¬” > | Знак отрицания | U+00AC | ISOnum |
| <!ENTITY shy CDATA “­” > | Мягкий дефис | U+00AD | ISOnum |
| <!ENTITY reg CDATA “®”> | Знак зарегистрированной торговой марки | U+00AE | ISOnum |
| <!ENTITY macr CDATA “¯” > | Знак долготы над гласным = черта над | U+00AF | ISOdia |
| <!ENTITY deg CDATA “°” > | Знак градуса | U+00B0 | ISOnum |
| <!ENTITY plusmn CDATA “±” > | Знак плюс-минус | U+00B1 | ISOnum |
| <!ENTITY sup2 CDATA “²” > | 2 в верхнем индексе = знак квадрата | U+00B2 | ISOnum |
| <!ENTITY sup3 CDATA “³” > | 3 в верхнем индексе = знак куба | U+00B3 | ISOnum |
| <!ENTITY acute CDATA “´” > | Резкое ударение | U+00B4 | ISOdia |
| <!ENTITY micro CDATA “µ” > | Знак микро | U+00B5 | ISOnum |
| <!ENTITY a CDATA “¶” > | Знак параграфа | U+00B6 | ISOnum |
| <!ENTITY middot CDATA “·” > | Центральная точка | U+00B7 | ISOnum |
| <!ENTITY cedil CDATA “¸” > | Седиль | U+00B8 | ISOdia |
| <!ENTITY sup1 CDATA “¹” > | 1 в верхнем индексе | U+00B9 | ISOnum |
| <!ENTITY ordm CDATA “º” > | Индикатор мужского начала | U+00BA | ISOnum |
| <!ENTITY raquo CDATA “»” > | Правая двойная угловая кавычка | U+00BB | ISOnum |
| <!ENTITY frac14 CDATA “¼” > | Символ 1/4 | U+00BC | ISOnum |
| <!ENTITY frac12 CDATA “½” > | Символ 1/2 | U+00BD | ISOnum |
| <!ENTITY frac34 CDATA “¾” > | Символ 3/4 | U+00BE | ISOnum |
| <!ENTITY iquest CDATA “¿”” > | Перевернутый знак вопроса | U+00BF | ISOnum |
| <!ENTITY Agrave CDATA “À” > | Латинская прописная буква A с глухим ударением | U+00C0 | ISOlat1 |
| <!ENTITY Aacute CDATA “Á” > | Латинская прописная буква A с ударением | U+00C1 | ISOlat1 |
| <!ENTITY Acirc CDATA “” > | Латинская прописная буква A центральным ударением | U+00C2 | ISOlat1 |
| <!ENTITY Atilde CDATA “Ô > | Латинская прописная буква A с тильдой | U+00C3 | ISOlat1 |
| <!ENTITY Auml CDATA “Ä” > | Латинская прописная буква A с умляутом, (диэрезой) | U+00C4 | ISOlat1 |
| <!ENTITY Aring CDATA “Å” > | Латинская прописная буква A с кружочком сверху | U+00C5 | ISOlat1 |
| <!ENTITY Aelig CDATA “Æ” > | Латинская прописная буква AE | U+00C6 | ISOlat1 |
| <!ENTITY Ccedil CDATA “Ç” > | Латинская прописная буква C с седилью | U+00C7 | ISOlat1 |
| <!ENTITY Egrave CDATA “È” > | Латинская прописная буква E с глухим ударением | U+00C8 | ISOlat1 |
| <!ENTITY Eacute CDATA “É” > | Латинская прописная буква E с ударением | U+00C9 | ISOlat1 |
| <!ENTITY Ecirc CDATA “Ê” | Латинская прописная буква E с циркумфлексом | U+00CA | ISOlat1 |
| <!ENTITY Euml CDATA “Ë” > | Латинская прописная буква E с диэрезой | U+00CB | ISOlat1 |
| <!ENTITY Igrave CDATA “Ì” > | Латинская прописная буква I с глухим ударением | U+00CC | ISOlat1 |
| <!ENTITY Iacute CDATA “Í” > | Латинская прописная буква I с ударением | U+00CD | ISOlat1 |
| <!ENTITY Icirc CDATA “Δ > | Латинская прописная буква I с циркумфлексом сверху | U+00CE | ISOlat1 |
| <!ENTITY Iuml CDATA “Ï” > | Латинская прописная буква I с диэрезой (умляутом) | U+00CF | ISOlat1 |
| <!ENTITY ETH CDATA “Д > | Латинская прописная буква ETH | U+00D0 | ISOlat1 |
| <!ENTITY Ntilde CDATA “Ñ” > | Латинская прописная буква N с тильдой | U+00D1 | ISOlat1 |
| <!ENTITY Ograve CDATA “Ò” > | Латинская прописная буква O с тупым ударением | U+00D2 | ISOlat1 |
| <!ENTITY Oacute CDATA “Ó” > | Латинская прописная буква O с ударением | U+00D3 | ISOlat1 |
| <!ENTITY Ocirc CDATA “Ô” > | Латинская прописная буква O с кружочком сверху | U+00D4 | ISOlat1 |
| <!ENTITY Otilde CDATA “Õ” > | Латинская прописная буква O с тильдой | U+00D5 | ISOlat1 |
| <!ENTITY Ouml CDATA “Ö” > | Латинская прописная буква O с диэрезой (умляутом) | U+00D6 | ISOlat1 |
| <!ENTITY times CDATA “×” > | Знак умножения | U+00D7 | ISOnum |
| <!ENTITY Oslash CDATA “Ø” > | Латинская прописная буква O с косой чертой | U+00D8 | ISOlat1 |
| <!ENTITY Ugrave CDATA “Ù” > | Латинская прописная буква U с глухим ударением | U+00D9 | ISOlat1 |
| <!ENTITY Uacute CDATA “Ú” > | Латинская прописная буква U с ударением | U+00DA | ISOlat1 |
| <!ENTITY Ucirc CDATA “Û” > | Латинская прописная буква U с циркумфлексом сверху | U+00DB | ISOlat1 |
| <!ENTITY Uuml CDATA “Ü” > | Латинская прописная буква U с тремой (умляутом) | U+00DC | ISOlat1 |
| <!ENTITY Yacute CDATA “Ý” > | Латинская прописная буква Y с ударением | U+00DD | ISOlat1 |
| <!ENTITY THORN CDATA “Þ” > | Латинская прописная буква THORN | U+00DE | ISOlat1 |
| <!ENTITY szlig CDATA “ß” > | Латинская строчная буква sharp s = ess-zed | U+00DF | ISOlat1 |
| <!ENTITY agrave CDATA “à” > | Латинская строчная буква a с глухим ударением | U+00E0 | ISOlat1 |
| <!ENTITY aacute CDATA “á” > | Латинская строчная буква a с ударением | U+00E1 | ISOlat1 |
| <!ENTITY acirc CDATA "â"> | Латинская строчная буква a с кружочком сверху | U+00E2 | ISOlat1 |
| <!ENTITY atilde CDATA "ã"> | Латинская строчная буква a с тильдой | U+00E3 | ISOlat1 |
| <!ENTITY auml CDATA "ä"> | Латинская строчная буква a с тремой (умляутом) | U+00E4 | ISOlat1 |
| <!ENTITY aring CDATA "å"> | Латинская строчная буква a с кружочком сверху | U+00E5 | ISOlat1 |
| <!ENTITY aelig CDATA "æ"> | Латинская строчная буква ae = латинская строчная лигатура ae | U+00E6 | ISOlat1 |
| <!ENTITY ccedil CDATA "ç"> | Латинская строчная буква c с седилью | U+00E7 | ISOlat1 |
| <!ENTITY egrave CDATA "è"> | Латинская строчная буква e с глухим ударением | U+00E8 | ISOlat1 |
| <!ENTITY eacute CDATA "é"> | Латинская строчная буква e с ударением | U+00E9 | ISOlat1 |
| <!ENTITY ecirc CDATA "ê"> | Латинская строчная буква e с циркумфлексом сверху | U+00EA | ISOlat1 |
| <!ENTITY euml CDATA "ë"> | Латинская строчная буква e с тремой (умляутом) | U+00EB | ISOlat1 |
| <!ENTITY igrave CDATA "ì"> | Латинская строчная буква i с глухим ударением | U+00EC | ISOlat1 |
| <!ENTITY iacute CDATA "í"> | Латинская строчная буква i с ударением | U+00ED | ISOlat1 |
| <!ENTITY icirc CDATA "î"> | Латинская строчная буква i с циркумфлексом сверху | U+00EE | ISOlat1 |
| <!ENTITY iuml CDATA "ï"> | Латинская строчная буква i с тремой (умляутом) | U+00EF | ISOlat1 |
| <!ENTITY eth CDATA "ð"> | Латинская строчная буква eth | U+00F0 | ISOlat1 |
| <!ENTITY ntilde CDATA "ñ"> | Латинская строчная буква n с тильдой | U+00F1 | ISOlat1 |
| <!ENTITY ograve CDATA "ò"> | Латинская строчная буква o с глухим ударением | U+00F2 | ISOlat1 |
| <!ENTITY oacute CDATA "ó"> | Латинская строчная буква o с ударением | U+00F3 | ISOlat1 |
| <!ENTITY ocirc CDATA "ô"> | Латинская строчная буква o с циркумфлексом сверху | U+00F4 | ISOlat1 |
| <!ENTITY otilde CDATA "õ"> | Латинская строчная буква o с тильдой | U+00F5 | ISOlat1 |
| <!ENTITY ouml CDATA "ö"> | Латинская строчная буква o с тремой (умляутом) | U+00F6 | ISOlat1 |
| <!ENTITY divide CDATA "÷"> | Знак деления | U+00F7 | ISOnum |
| <!ENTITY oslash CDATA "ø"> | Латинская строчная буква o с косой чертой | U+00F8 | ISOlat1 |
| <!ENTITY ugrave CDATA "ù"> | Латинская строчная буква u с глухим ударением | U+00F9 | ISOlat1 |
| <!ENTITY uacute CDATA "ú"> | Латинская строчная буква u с ударением | U+00FA | ISOlat1 |
| <!ENTITY ucirc CDATA "û"> | Латинская строчная буква u с циркумфлексом сверху | U+00FB | ISOlat1 |
| <!ENTITY uuml CDATA "ü"> | Латинская строчная буква u с тремой (умляутом) | U+00FC | ISOlat1 |
| <!ENTITY yacute CDATA "ý"> | Латинская строчная буква y с ударением | U+00FD | ISOlat1 |
| <!ENTITY thorn CDATA "þ"> | Латинская строчная буква thorn | U+00FE | ISOlat1 |
| <!ENTITY yuml CDATA "ÿ"> | Латинская строчная буква y с тремой (умляутом) | U+00FF | ISOlat1 |
/p> Эталонные символьные объекты для символов, математических символов и греческих букв
Эталонные символьные объекты в этом разделе производят символы, которые могут быть представлены глифами из широко известного шрифта Adobe Symbol, включая греческие буквы, различные скобки, а также секцией математических операторов (+ . - и т.д.).
Чтобы поддержать эти объекты агенты пользователя могут поддерживать целиком ISO10646 или использовать другие средства. Отображение глифов для этих символов может быть реализовано через отображение соответствующих символов ISO10646 или другими способами, такими как установление внутреннего соответствия перечисленных объектов, коды символов и порядковые номера символов в заданном шрифтовом наборе.
Использование греческих символов. Этот символьный набор содержит все буквы, используемые в современном греческом алфавите. Однако, он не включает в себя греческую пунктуацию, символы со знаками ударения или безпробельные акценты (tonos, dialytika), необходимые для их формирования. Здесь нет архаичных букв, уникальных коптских букв или комбинированных букв политонического греческого языка. Определенные здесь объекты предназначены не для представления современного греческого текста, а для применения в технических математических текстах.
Список символов
<!-- Математические, греческие и другие символы HTML -->
<!-- Character entity set. Typical invocation:
<!ENTITY % HTMLsymbol PUBLIC
"-//W3C//ENTITIES Symbols//EN//HTML">
%HTMLsymbol; -->
<!-- Ниже приводится набор соответствующих объектов ISO, если не введены новые имена. Новые имена (напр., не из списка ISO 8879) не противоречат другим существующим именам объектов ISO 8879. Коды символов ISO 10646 даны для каждого символа в шестнадцатеричной нотации. Значения CDATA приведены в десятичном виде ISO 10646 и относятся к символьному набору документа. Имена соответствуют Unicode 2.0. -->
| Греческие символы (ISOgrk3) | ||
| Определение | Название символа | Уникод |
| <!ENTITY Alpha CDATA "Α"> | Греческая прописная альфа (A) | U+0391 |
| <!ENTITY Beta CDATA "Β"> | Греческая прописная бета (B) | U+0392 |
| <!ENTITY Gamma CDATA "Γ"> | Греческая прописная гамма (G) | U+0393 |
| <!ENTITY Delta CDATA "Δ"> | Греческая прописная дельта (D) | U+0394 |
| <!ENTITY Epsilon CDATA "Ε"> | Греческая прописная эпсилон (E) | U+0395 |
| <!ENTITY Zeta CDATA "Ζ"> | Греческая прописная зета (Z) | U+0396 |
| <!ENTITY Eta CDATA "Η"> | Греческая прописная эта (H) | U+0397 |
| <!ENTITY Theta CDATA "Θ"> | Греческая прописная тэта (Q) | U+0398 |
| <!ENTITY Iota CDATA "Ι"> | Греческая прописная иота (I) | U+0399 |
| <!ENTITY Kappa CDATA "Κ"> | Греческая прописная каппа (K) | U+039A |
| <!ENTITY Lambda CDATA "Λ"> | Греческая прописная лямбда (L) | U+039B |
| <!ENTITY Mu CDATA "Μ"> | Греческая прописная мю (M) | U+039C |
| <!ENTITY Nu CDATA "Ν"> | Греческая прописная ню (N) | U+039D |
| <!ENTITY Xi CDATA "Ξ"> | Греческая прописная кси (X) | U+039E |
| <!ENTITY Omicron CDATA "Ο"> | Греческая прописная омикрон (O) | U+039F |
| <!ENTITY Pi CDATA "Π"> | Греческая прописная пи (P) | U+03A0 |
| <!ENTITY Rho CDATA "Ρ"> | Греческая прописная ро (R) | U+03A1 |
| <!ENTITY Sigma CDATA "Σ">*) | Греческая прописная сигма (S) | U+03A3 |
| <!ENTITY Tau CDATA "Τ"> | Греческая прописная тау (T) | U+03A4 |
| <!ENTITY Upsilon CDATA "Υ"> | Греческая прописная ипсилон (U) | U+03A5 |
| <!ENTITY Phi CDATA "Φ"> | Греческая прописная фи (F) | U+03A6 |
| <!ENTITY Chi CDATA "Χ"> | Греческая прописная хи (C) | U+03A7 |
| <!ENTITY Psi CDATA "Ψ"> | Греческая прописная пси (Y) | U+03A8 |
| <!ENTITY Omega CDATA "Ω"> | Греческая прописная омега (W) | U+03A9 |
| <!ENTITY alpha CDATA "α"> | Греческая строчная альфа (a) | U+03B1 |
| <!ENTITY beta CDATA "β"> | Греческая строчная бета (b) | U+03B2 |
| <!ENTITY gamma CDATA "γ"> | Греческая строчная гамма (g) | U+03B3 |
| <!ENTITY delta CDATA "δ"> | Греческая строчная дельта (d) | U+03B4 |
| <!ENTITY epsilon CDATA "ε"> | Греческая строчная эпислон (e) | U+03B5 |
| <!ENTITY zeta CDATA "ζ"> | Греческая строчная зета (z) | U+03B6 |
| <!ENTITY eta CDATA "η"> | Греческая строчная эта (h) | U+03B7 |
| <!ENTITY theta CDATA "θ"> | Греческая строчная тета (q) | U+03B8 |
| <!ENTITY iota CDATA "ι"> | Греческая строчная иота (i) | U+03B9 |
| <!ENTITY kappa CDATA "κ"> | Греческая строчная каппа (k) | U+03BA |
| <!ENTITY lambda CDATA "λ"> | Греческая строчная лямбда (l) | U+03BB |
| <!ENTITY mu CDATA "μ" | Греческая строчная мю (m) | U+03BC |
| <!ENTITY nu CDATA "ν"> | Греческая строчная ню (n) | U+03BD |
| <!ENTITY xi CDATA "ξ"> | Греческая строчная кси (x) | U+03BE |
| <!ENTITY omicron CDATA "ο"> | Греческий строчный омикрон (o) | U+03BF |
| <!ENTITY pi CDATA "π"> | Греческая строчная пи (p) | U+03C0 |
| <!ENTITY rho CDATA "ρ"> | Греческая строчная ро (r) | U+03C1 |
| <!ENTITY sigmaf CDATA "ς"> | Греческая строчная финальная сигма | U+03C2 |
| <!ENTITY sigma CDATA "σ"> | Греческая строчная сигма (s) | U+03C3 |
| <!ENTITY tau CDATA "τ"> | Греческая строчная тау | U+03C4 |
| <!ENTITY upsilon CDATA "υ"> | Греческий строчный ипсилон (u) | U+03C5 |
| <!ENTITY phi CDATA "φ"> | Греческая строчная фи (j) | U+03C6 |
| <!ENTITY chi CDATA "χ"> | Греческая строчная хи (c) | U+03C7 |
| <!ENTITY psi CDATA "ψ"> | Греческая строчная пси (y) | U+03C8 |
| <!ENTITY omega CDATA "ω"> | Греческая строчная омега (w) | U+03C9 |
| <!ENTITY thetasym CDATA "ϑ"> | Греческий тета символ | U+03D1 |
| <!ENTITY upsih CDATA "ϒ"> | Греческий ипсилон с крючком | U+03D2 |
| <!ENTITY piv CDATA "ϖ"> | Греческий символ пи | U+03D6 |
/p> *) Не существует Sigmaf, и нет также символа U+03A2
Общая пунктуация |
|||
| Определение | Название символа | Уникод | Название набора |
| <!ENTITY ensp CDATA " "> | en пробел | U+2002 | ISOpub |
| <!ENTITY emsp CDATA " "> | em пробел | U+2003 | ISOpub |
| <!ENTITY thinsp CDATA " "> | Узкий пробел | U+2009 | ISOpub |
| <!ENTITY zwnj CDATA "‌"> | Разрываемый соединитель нулевой ширины | U+200C | NEW RFC 2070 |
| <!ENTITY zwj CDATA "‍"> | Соединитель нулевой ширины | U+200D | NEW RFC 2070 |
| <!ENTITY lrm CDATA "‎"> | Знак слево-направо | U+200E | NEW RFC 2070 |
| <!ENTITY rlm CDATA "‏"> | Знак справа-налево | U+200F | NEW RFC 2070 |
| <!ENTITY ndash CDATA "–"> | en дефис | U+2013 | ISOpub |
| <!ENTITY mdash CDATA "—"> | em дефис | U+2014 | ISOpub |
| <!ENTITY lsquo CDATA "‘"> | Левая кавычка | U+2018 | ISOnum |
| <!ENTITY rsquo CDATA "’"> | Правая кавычка | U+2019 | ISOnum |
| <!ENTITY sbquo CDATA "‚"> | Single low-9 quotation mark | U+201A | NEW |
| <!ENTITY ldquo CDATA "“"> | Левая двойная кавычка | U+201C | ISOnum |
| <!ENTITY rdquo CDATA "”"> | Правая двойная кавычка | U+201D | ISOnum |
| <!ENTITY bdquo CDATA "„"> | double low-9 quotation mark | U+201E | NEW |
| <!ENTITY dagger CDATA "†" | Кинжал † | U+2020 | ISOpub |
| <!ENTITY Dagger CDATA "‡"> | Двойной кинжал ‡ | U+2021 | ISOpub |
| <!ENTITY bull CDATA "•"> | Маленький черный кружочек (bullet) • **) | U+2022 | ISOpub |
| <!ENTITY hellip CDATA "…"> | Многоточие = трехточечный пунктир … | U+2026 | ISOpub |
| <!ENTITY permil CDATA "‰" | Знак промиль ‰ | U+2030 | ISOtech |
| <!ENTITY prime CDATA "′"> | Прайм = минуты = фут | U+2032 | ISOtech |
| <!ENTITY Prime CDATA "″"> | Дубль прайм = секунды = дюймы | U+2033 | ISOtech |
| <!ENTITY lsaquo CDATA "‹"> | Одиночная, угловая левая кавычка | U+2039 | Предложено ISO |
| <!ENTITY rsaquo CDATA "›"> | Одиночная, угловая правая кавычка | U+203A | Предложено ISO |
| <!ENTITY oline CDATA "‾"> | Верхняя черта | U+203E | NEW |
| <!ENTITY frasl CDATA "⁄"> | Косая черта дроби | U+2044 | NEW |
| <!ENTITY euro CDATA "€"> | Знак евро € | U+20AC | NEW |
/p> **) bullet не тождественен оператору bullet, U+2219
Буквоподобные символы |
|||
| Определение | Название символа | Уникод | Название набора |
| <!ENTITY weierp CDATA "℘"> | Прописная письменная P | U+2118 | ISOamso |
| <!ENTITY image CDATA "ℑ"> | Прописная жирная буква I = мнимая часть | U+2111 | ISOamso |
| <!ENTITY real CDATA "ℜ"> | Прописная жирная буква R = символ действительной части | U+211C | ISOamso |
| <!ENTITY trade CDATA "™"> | Символ торговой марки | U+2122 | ISOnum |
| <!ENTITY alefsym CDATA "ℵ"> | Символ alef ***) | U+2135 | NEW |
Стрелки |
|||
| Определение | Название символа | Уникод | Название набора |
| <!ENTITY larr CDATA "←"> | Стрелка влево | U+2190 | ISOnum |
| <!ENTITY uarr CDATA "↑"> | Стрелка вверх | U+2191 | ISOnum |
| <!ENTITY rarr CDATA "→"> | Стрелка вправо | U+2192 | ISOnum |
| <!ENTITY darr CDATA "↓"> | Стрелка вниз | U+2193 | ISOnum |
| <!ENTITY harr CDATA "↔"> | Двухсторонняя горизонтальная стрелка | U+2194 | ISOamsa |
| <!ENTITY crarr CDATA "↵"> | Стрелка вниз с поворотом налево = возврат каретки | U+21B5 | NEW |
| <!ENTITY lArr CDATA "⇐"> | Двойная стрелка влево +) | U+21D0 | ISOtech |
| <!ENTITY uArr CDATA "⇑"> | Двойная стрелка вверх | U+21D1 | ISOamsa |
| <!ENTITY rArr CDATA "⇒"> | Двойная стрелка вправо ++) | U+21D2 | ISOtech |
| <!ENTITY dArr CDATA "⇓"> | Двойная стрелка вниз | U+21D3 | ISOamsa |
| <!ENTITY hArr CDATA "⇔"> | Двойная двухсторонняя стрелка | U+21D4 | ISOamsa |
Так ? lArr может использоваться для ' is implied by' как это рекомендует ISOtech
++) Уникод не утверждает, что это 'implies' символ, но не имеет другого символа для этих целей, таким образом, ? rArr может использоваться для 'implies' как это рекомендует ISOtech
Математические операторы |
|||
| Определение | Название символа | Уникод | Название набора |
| <!ENTITY forall CDATA "∀"> | Для всех ? | U+2200 | ISOtech |
| <!ENTITY part CDATA "∂"> | Частный дифференциал ? | U+2202 | ISOtech |
| <!ENTITY exist CDATA "∃"> | Существует ? | U+2203 | ISOtech |
| <!ENTITY empty CDATA "∅"> | Пустой набор = диаметр ? | U+2205 | ISOamso |
| <!ENTITY nabla CDATA "∇"> | Набла = обратная разница | U+2207 | ISOtech |
| <!ENTITY isin CDATA "∈"> | Элемент чего-то ? | U+2208 | ISOtech |
| <!ENTITY notin CDATA "∉"> | Не элемент чего-то ? | U+2209 | ISOtech |
| <!ENTITY ni CDATA "∋"> | Содержит, как член ? | U+220B | ISOtech |
| <!ENTITY prod CDATA "∏"> | n-кратное произведение= знак произведения ?#) | U+220F | ISOamsb |
| <!ENTITY sum CDATA "∑"> | n-кратная сумма ?##) | U+2211 | ISOamsb |
| <!ENTITY minus CDATA "−"> | Знак минус ? | U+2212 | ISOtech |
| <!ENTITY lowast CDATA "∗"> | Оператор звездочка ? | U+2217 | ISOtech |
| <!ENTITY radic CDATA "√"> | Квадратный корень = знак радикала v | U+221A | ISOtech |
| <!ENTITY prop CDATA "∝"> | пропорционально ? | U+221D | ISOtech |
| <!ENTITY infin CDATA "∞"> | Бесконечность (Ґ ) | U+221E | ISOtech |
| <!ENTITY ang CDATA "∠"> | Угол (Р ) | U+2220 | ISOamso |
| <!ENTITY and CDATA "∧"> | Логическое И =призма ? | U+2227 | ISOtech |
| <!ENTITY or CDATA "∨"> | Логическое ИЛИ ? | U+2228 | ISOtech |
| <!ENTITY cap CDATA "∩"> | Пересечение ? | U+2229 | ISOtech |
| <!ENTITY cup CDATA "∪"> | Объединение ? | U+222A | ISOtech |
| <!ENTITY int CDATA "∫"> | Интеграл ? | U+222B | ISOtech |
| !ENTITY there4 CDATA "∴"> | Следовательно ? | U+2234 | ISOtech |
| <!ENTITY sim CDATA "∼"> | Оператор тильда = изменяется с = подобно тому ###) | U+223C | ISOtech |
| <!ENTITY cong CDATA "≅"> | Приблизительно равно ? | U+2245 | ISOtech |
| <!ENTITY asymp CDATA "≈"> | Почти равно= асимптотическое приближение к ? | U+2248 | ISOamsr |
| <!ENTITY ne CDATA "≠"> | Не равно (№ ) | U+2260 | ISOtech |
| <!ENTITY equiv CDATA "≡"> | Идентично = тождественно равно (є ) | U+2261 | ISOtech |
| <!ENTITY le CDATA "≤"> | Меньше или равно (Ј ) | U+2264 | ISOtech |
| <!ENTITY ge CDATA "≥"> | Больше или равно ? | U+2265 | ISOtech |
| <!ENTITY sub CDATA "⊂"> | Входит в ? | U+2282 | ISOtech |
| <!ENTITY sup CDATA "⊃"> | Включает в себя L | U+2283 | ISOtech |
| <!ENTITY nsub CDATA "⊄"> | Не является субнабором чего-то ? | U+2284 | ISOamsn |
| <!ENTITY sube CDATA "⊆"> | Входит в или тождественен ? | U+2286 | ISOtech |
| <!ENTITY supe CDATA "⊇"> | Включает в себя или тождественен ? | U+2287 | ISOtech |
| <!ENTITY oplus CDATA "⊕"> | Плюс в кружочке = direct sum (Е ) | U+2295 | ISOamsb |
| <!ENTITY otimes CDATA "⊗"> | Векторное произведение = знак умножения в кружочке (Д ) | U+2297 | ISOamsb |
| <!ENTITY perp CDATA "⊥"> | Ортогонально = перпендикулярно (^ ) | U+22A5 | ISOtech |
| <!ENTITY sdot CDATA "⋅"> | Оператор точка ####) | U+22C5 | ISOamsb |
/p> #) prod не тождественен символу U+03A0 ' греческая прописная буква pi' хотя один и тот же глиф может быть использован для отображения обоих
##) sum не тождественен символу U+03A3 'греческая прописная буква сигма’ хотя один и тот же глиф может быть использован для отображения обоих
###) tilde оператор не тождественен символу U+007E, хотя один и тот же глиф может быть использован для отображения обоих
####) Оператор dot не тождественен символу U+00B7 центральная точка
Различные технические символы |
|||
| Определение | Название символа | Уникод | Название набора |
| <!ENTITY lceil CDATA "⌈"> | left ceiling = apl upstile | U+2308 | ISOamsc |
| <!ENTITY rceil CDATA "⌉"> | right ceiling (` ) | U+2309 | ISOamsc |
| <!ENTITY lfloor CDATA "⌊"> | left floor = apl downstile | U+230A | ISOamsc |
| <!ENTITY rfloor CDATA "⌋"> | right floor | U+230B | ISOamsc |
| <!ENTITY lang CDATA "〈"> | левая угловая скобка | U+2329 | ISOtech |
| <!ENTITY rang CDATA "〉"> | правая угловая скобка= закрывающая скобка | U+232A | ISOtech |
| Геометрические формы | |||
| Определение | Название символа | Уникод | Название набора |
| <!ENTITY loz CDATA "◊"> | ромб (а ) | U+25CA | ISOpub |
| Различные символы | |||
| Определение | Название символа | Уникод | Название набора |
| <!ENTITY spades CDATA "♠"> | черные пики (Є ) | U+2660 | ISOpub |
| <!ENTITY clubs CDATA "♣"> | черные крести=лист кислицы (§ ) | U+2663 | ISOpub |
| <!ENTITY hearts CDATA "♥"> | черные черви (© ) | U+2665 | ISOpub |
| <!ENTITY diams CDATA "♦"> | черные бубни (Ё ) | U+2666 | ISOpub |
Эталонные символьные объекты в этой секции предназначены для символов разметки текста (markup) (они те же, что и в HTML 2.0 и 3.2), для обозначения пробелов и дефисов.
Остальные символы в этой секции используются для интернационализации.
Добавлены некоторые символы из CP-1252, которые не встречаются в наборах HTMLlat1 или HTMLsymbol. Все они из диапазона 128 - 159 символьного набора cp-1252. Эти объекты позволяют обозначать символы независимо от платформы.
Для поддержки этих объектов агенты пользователя могут поддерживать полный набор ISO10646 или использовать другие средства. Отображение глифов этих символов может быть реализовано, если возможно отображение символов ISO10646 или другими средствами.
Список символов
<!-- Набор символьных объектов:
<!ENTITY % HTMLspecial PUBLIC "-//W3C//ENTITIES Special//EN//HTML">
%HTMLspecial; -->
<!-- Используется набор объектов ISO, если не введены новые имена. Новые имена (напр., не из списка ISO 8879) не будут конфликтовать с любыми существующими именами объектов ISO 8879. Коды символов ISO 10646 приводятся для всех символов в шестнадцатеричном виде. Значения CDATA представляют собой десятичные коды ISO 10646. Имена соответствуют именам Unicode 2.0. -->
Специальные символы HTML. Контроли C0 и базовый латинский |
|||
| Определение | Название символа | Уникод | Название набора |
| <!ENTITY quot CDATA """> | Кавычка = APL quote | U+0022 | ISOnum |
| <!ENTITY amp CDATA "&"> | Знак & | U+0026 | ISOnum |
| <!ENTITY lt CDATA "<"> | Знак меньше чем | U+003C | ISOnum |
| <!ENTITY gt CDATA ">"> | Знак больше чем | U+003E | ISOnum |
Латинские буквы, расширение А |
|||
| Определение | Название символа | Уникод | Название набора |
| <!ENTITY OElig CDATA "Œ"> | Латинская прописная лигатура OE | U+0152 | ISOlat2 |
| <!ENTITY oelig CDATA "œ"> | Латинская строчная лигатура oe | U+0153 | ISOlat2 |
| <!ENTITY Scaron CDATA "Š"> | Латинская прописная буква S с короной | U+0160 | ISOlat2 |
| <!ENTITY scaron CDATA "š"> | Латинская строчная буква s с короной | U+0161 | ISOlat2 |
| <!ENTITY Yuml CDATA "Ÿ"> | Латинская прописная буква Y с тремой (умляутом) | U+0178 | ISOlat2 |
Латинские буквы, расширение B |
|||
| Определение | Название символа | Уникод | Название стандарта |
| <!ENTITY fnof CDATA "ƒ" --> | Латинская строчная буква f с крючком = флорин | U+0192 | ISOtech |
Модификаторы букв |
|||
| Определение | Название символа | Уникод | Название стандарта |
| <!ENTITY circ CDATA "ˆ"> | Модификатор буквы – облегченное ударение | U+02C6 | ISOpub |
| <!ENTITY tilde CDATA "˜"> | Малая тильда | U+02DC | ISOdia |
/p>
Статический алгоритм Хафмана
2.6.5 Статический алгоритм Хафмана
Статический алгоритм Хафмана можно считать классическим (см. также Р. Галлагер. Теория информации и надежная связь. “Советское радио”, Москва, 1974.) Определение статический в данном случае отностится к используемым словарям. Смотри также www.ics.ics.uci.edu/~dan/pubs/DataCompression.html (Debra A. Lelewer и Daniel S. Hirschberg).
Пусть сообщения m(1),…,m(n) имеют вероятности P(m(1)),… P(m(n)) и пусть для определенности они упорядочены так, что P(m(1)) і P(m(2)) і … і P(m(N)). Пусть x1,…, xn – совокупность двоичных кодов и пусть l1, l2,…, lN – длины этих кодов. Задачей алгоритма является установление соответствия между m(i) и xj. Можно показать, что для любого ансамбля сообщений с полным числом более 2 существует двоичный код, в котором два наименее вероятных кода xN и xN-1 имеют одну и ту же длину и отличаются лишь последним символом: xN имеет последний бит 1, а xN-1 – 0. Редуцированный ансамбль будет иметь свои два наименее вероятные сообщения сгруппированными вместе. После этого можно получить новый редуцированный ансамбль и так далее. Процедура может быть продолжена до тех пор, пока в очередном ансамбле не останется только два сообщения. Процедура реализации алгоритма сводится к следующему (см. Рисунок 2.6.5.1). Сначала группируются два наименее вероятные сообщения, предпоследнему сообщению ставится в соответствие код с младшим битом, равным нулю, а последнему – код с единичным младшим битом (на рисунке m(4) и m(5)). Вероятности этих двух сообщений складываются, после чего ищутся два наименее вероятные сообщения во вновь полученном ансамбле (m(3) и m`(4); p(m`(4)) = p(m(4)) + P(m(5))).
Структура передаваемой информации (каждое слово содержит или бита)
Рисунок 4.7.1.2. Структура передаваемой информации (каждое слово содержит 32 или 64 бита)
Каждый пакет содержит в конце субполе контроля четности. Все сигналы кроме соединения (interconnect) используют приемники и передатчики эмиттерно-связанной логики (ECL). Формат I-поля показан на рис 4.1.7.3.
Структура ресурса и объекта
Рисунок 4.5.6.1.2. Структура ресурса и объекта
Протокол HTTP представляет собой протокол запросов-откликов. Клиент посылает запрос серверу в форме, определяющей метод, URI и версию протокола. В конце запроса следует MIME-подобное сообщение, содержащее модификаторы, информацию о клиенте и, возможно, другие данные. Сервер откликается, посылая статусную строку, которая включает в себя версию протокола, код результата (успех/неудача) и MIME-подобное сообщение, в котором содержатся данные о сервере и метаинформация.
Большинство HTTP-обменов инициируются пользователем и состоят из запросов ресурсов, имеющихся на определенном сервере. В простейшем случае такой запрос может быть реализован путем соединения пользовательского агента (UA) и базового сервера.
Более сложная ситуация возникает, когда присутствует один или более посредников в цепочке обслуживания запроса/отклика. Существует три стандартные формы посредников: прокси, туннель и внешний порт (gateway). Прокси представляет собой агент переадресации, получающий запрос для URI, переписывающий все сообщение или его часть и отправляющий переделанный запрос серверу, указанному URI. Внешний порт (gateway) представляет собой приемник, который работает на уровень выше некоторых других серверов и транслирует, если необходимо, запрос нижележащему протоколу сервера. Туннель действует как соединитель точка-точка и не производит каких-либо видоизменений сообщений. Туннель используется тогда, когда нужно пройти через какую-то систему (например, Firewall) в условиях, когда эта система не понимает (не анализирует) содержимое сообщений.
Запрос -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
должна иметь как минимум
Таблица должна иметь как минимум одну группу колонок. В отсутствии определения группы считается, что таблица имеет одну группу колонок, включающую в себя все колонки таблицы. Атрибут width элемента colgroup определяет ширину по умолчанию каждой из колонок в группе. Формат “0*”, требующий минимальной ширины, может быть отменен элементом col.
должна содержать хотя
Таблица должна содержать хотя бы одну группу рядов. Каждая группа рядов делится на три секции: заголовок, собственно таблица и подпись под таблицей. Заголовок и подпись являются опционными. Элемент thead определяет заголовок, tfoot – подпись под таблицей, а элемент tbody - тело таблицы. thead, tfoot и tbody, если они присутствуют, должны содержать один или более рядов. Ниже приведен пример использования элементов thead, tfoot и tbody.
<table>
<thead>
<tr> … информация заголовка … |
align="justify"></thead>
<tfoot>
<tr> … информационная подпись под таблицей … |
</tfoot>
<tbody>
<tr> … первый ряд блока первых данных … |
|
<tr> … второй ряд блока первых данных … |
</tbody>
<tbody>
<tr> … первый ряд блока вторых данных … |
|
<tr> … второй ряд блока вторых данных … |
|
<tr> … третий ряд блока вторых данных … |
</tbody>
</table>
tfoot в рамках определения table должен появляться до tbody, так чтобы агент пользователя мог осуществлять разбор подписи до получения всех данных таблицы.
14.6. Опционные метки групп рядов
Когда таблица содержит только одно тело и не имеет заголовка и нижней подписи, начальная и конечная метки tbody могут быть опущены. Когда блок таблицы содержит заголовок, начальная и конечная метки элемента thead являются необходимыми. Конечная метка может быть опущена, когда далее следует стартовая метка tfoot или tbody. когда блок таблицы содержит нижняя подпись, необходима начальная метка элемента tfoot. Конечная метка может быть опущена, когда далее следуют начальная метка thead или tbody.
14.7. Группы колонок. Элементы colgroup и col
<!element colgroup - o (col*) >
<!attlist colgroup %attrs; |
-- %coreattrs, %i18n, %events -- |
|
span number 1 |
-- число колонок в группе по умолчанию -- |
|
width cdata #implied |
-- ширина колонки по умолчанию -- |
|
%CEllhalign; |
-- горизонтальное выравнивание в ячейках -- |
|
%CEllvalign; |
-- вертикальное выравнивание в ячейках -- > |
|
Определения атрибутов
span = integer
Атрибут в случае своего присутствия определяет число колонок в группе по умолчанию. Агент пользователя должен игнорировать этот атрибут, если текущая группа содержит один или более элементов col. Значение атрибута по умолчанию равно единице.
width = length
Атрибут определяет значение ширины колонки по умолчанию для текущей группы колонок. Кроме того, для стандартных значений пикселя и процента этот атрибут может иметь специальную форму “0*”, которая означает, что ширина каждой колонки в группе должна иметь минимальную ширину для размещения имеющегося текста.
может быть отображена следующим образом
Таблица может быть отображена следующим образом.
A test table with merged cells
|
Average |
Other |
misc |
||
height |
weight |
|||
males |
1.9 | 0.003 | ||
females |
1.7 | 0.002 |
Пример 2 иллюстрирует группировку рядов и колонок. Пример взят из “developing international software”, by nadine kano.
Code-page support in Microsoft Window
| Code-page ID |
Name | ACP | OEMCP | Windows NT 3.1 |
Windows NT 3.51 |
Windows 95 |
| 1200 1250 1251 1252 1253 1254 1255 1256 1257 1361 |
unicode (BMP of ISO/IEC-10646) windows 3.1 eastern european windows 3.1 cyrillic windows 3.1 us (ansi) windows 3.1 greek windows 3.1 turkish hebrew arabic baltic korean |
x x x x x x x x x |
|
x x x x x x
|
x x x x x x ** |
* x x x x x x x x x |
| 437 708 709 710 720 |
MS-DOS united states arabic (asmo 708) arabic (asmo 449+, bcon v4) arabic (transparent arabic) arabic (transparent asmo) |
x x x x x |
x
|
x | x x x x x |
15. Информация о пути. Элемент base
<!element base - o empty>
<!attlist base href %url #required
target cdata #implied -- где развернуть подключенный ресурс -- >
Описание атрибута
href = url
Этот атрибут задает абсолютный url, который используется как базовый при определении относительных url.
В HTML проходы всегда задаются с помощью URL. Относительные URL получаются на основе базового URL, который может быть получен различными путями. Элемент base позволяет описать базовый URL явно. Например:
<html>
<head>
<base href=http://www.barre.fr/fou/intro.html>
</head>
….
</html>
Относительный URL “../gee/foo/html” будет в этом случае получен в виде:
http://www.barre.fr/gee/foo.html
15.1. Связи и якоря
HTML-связь представляет собой соединение одного WWW-ресурса с другим.
Определение связей и якорей
В HTML любая связь имеет два конца и направление. Связь начинается в источнике и завершается в месте назначения. Любое описание связи определяет оба эти конца. Один конец задается местом описания связи, другой – атрибутом этой связи. Связь соответствует какому-то WWW-ресурсу (HTML-документу, изображению, видео-клипу, текущему документу, звуковому файлу и т.д.). Конец связи может быть также задан якорем. Якорь – это именованный указатель на определенную часть документа. Связь устанавливает соответствие между источником и местом назначения. Но помимо этого связь может определять тип информации. Связи могут носить самый разный характер, например, указания “next” или “previous” также задают определенные связи. Связи могут использоваться пользователем и для определения порядка печати документов. Атрибут rel определяет, что связь имеет начало в текущем документе. Атрибут rev указывает, что описанная связь имеет в качестве места назначения текущий документ. В HTML имеется два элемента, определяющие связь, это link и a.
Link может появиться в секции head HTML-документа. Этот элемент определяет взаимоотношение между зоной текущего документа и другим ресурсом.
Элемент A может появиться в теле документа, он устанавливает связь между зоной текущего документа и другим ресурсом. Элемент a в отличие от link может иметь содержимое (текст, изображения и т.д.). Другим важным отличием этих двух элементов является то, что А интерпретируется агентом пользователя как указание “извлечь ресурс, находящийся на другом конце связи”. Извлеченный ресурс может обрабатываться агентом пользователя разными способами:
Открыть новый документ в том же окне, открыть документ в другом окне, запустить новую программу и т.д.
Атрибут title может быть установлен в элементах для выдачи дополнительной информации о природе связи.
15.2. Элементы, определяющие якоря
Существует два способа специфицировать якоря в HTML-документах.
Использовать элемент А (служит для формирования связей и якорей).
Применить атрибут id любого элемента.
Так как документы могут быть написаны на разных языках, link и a поддерживают атрибуты lang, dir и charset.
15.3. Элемент А
<!element a - - (%inline)* -(a)>
<!attlist a
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| charset cdata #implied | -- перекодировка символов в подключенном ресурсе -- | |
| name cdata #implied | -- именованный конец связи -- | |
| href %url #implied | -- url для подключенного ресурса -- | |
| target cdata #implied | -- где развернуть ресурс -- | |
| rel cdata #implied | -- типы прямых связей -- | |
| rev cdata #implied | -- типы обратных связей -- | |
| accesskey cdata #implied | -- символ ключа доступа -- | |
| shape %shape rect | -- для использования с object shapes -- | |
| coords %coords #implied | -- для использования с object shapes -- | |
| tabindex number #implied | -- положения табуляции -- > |
Описания атрибутов
name = cdata
Этот атрибут указывает на то, что элемент использован для описания якоря. Значение этого атрибута является уникальным именем якоря. Это имя действительно в пределах данного документа. Атрибут name работает в том же пространстве имен, что и атрибут ID.
href = url
Этот атрибут указывает на то, что элемент использован для описания связи. Значение атрибута равно положению одного из концов связи (другой конец задан положением этого элемента).
rel = cdata
Этот атрибут указывает на то, что источником связи является текущая позиция в документе. Значение Href в этом случае определяет место назначения связи. Значение rel специфицирует тип связи. Этот атрибут может включать в себя список типов связей, разделенных пробелами.
rev = cdata
Этот атрибут указывает на то, что место назначения связи соответствует текущей позиции в документе. Значение Href в этом случае определяет положение источника. Значение rev специфицирует тип связи. Этот атрибут может включать в себя список типов связей, разделенных пробелами.
charset = cdata
Этот атрибут специфицирует перекодировку символов для данной связи.
Значение этого атрибута должно быть именем “charset” описанным в RFC-2045. Значение по умолчанию этого атрибута равно “ISO-8859-1”.
Ниже приведен пример использования А-элемента.
<a href=http://www.3w.org/>w3c web site</a>
Эта ссылка указывает на базовую страницу консорциума WWW. Когда пользователь активирует эту связь, агент пользователя обратится к указанному ресурсу и откроет HTML-документ. Агент пользователя представляет ссылки в документе так, чтобы выделить их из текста (например, подчеркивает их). Чтобы сообщить агенту пользователя в явном виде, какой набор символов следует использовать при отображении, следует установить соответствующее значение атрибута charset.
<a href =http://www.w3.org/ charset=”ISO-8859-1”>w3c web site</a>
Ниже приведен пример, иллюстрирующий описание якоря с именем “anchor-one” в файле “one.html”.
… текст до якоря …
<a name=”anchor-oner”>this is the location of anchor one.</a>
… текст после якоря …
Это определение присваивает якорь зоне документа, содержащей текст “This is the location of anchor one”. Определив якорь, мы можем установить с ним связь из того же или постороннего документа. URL, который указывает на якорь, завершаются символом #, за которым следует имя якоря. Ниже приведены примеры такого URL.
Абсолютный URL: http://www.mycompany.com/one.html">http://www.mycompany.com/one.html#anchor-one
Относительный URL: ../one.html#anchor-one
Когда связь задана в пределах документа: #anchor-one
Таким образом, связь, определенная в файле “two.html”, который находится в том же каталоге, что и “one.html” имеет ссылку на якорь в виде:
<a href=”./one.html#anchor-one” anchor one</a>
Элемент А в следующем примере определяет якорь и связь в одно и то же время.
<a name=”anchor-two” href=”html://wwwsomecompany.com/people/ian/vocation/family.png”>
</a>
Этот пример содержит связь с www-ресурсом другого типа (png-изображение). Активация связи должна извлечь это изображение из сети и отобразить его.
15.4. Связи mailto
Автор может сформировать связи, которые не ведут к какому-либо документу, а реализуют отправку e-mail сообщения по некоторому адресу. Когда такая связь активизируется, агент пользователя вызывает почтовую программу. Для реализации таких связей введено значение mailto атрибута Href.
<a href=”mailto:semenov@ns.itep.ru”> yury semenov</a>
Когда пользователь активизирует эту связь, агент пользователя открывает почтовую программу и заносит в поле “to:” значение “semenov@ns.itep.ru”.
15.5. Вложенные связи
Связи и якоря, описанные элементом А не допускают вложения. Например, ниже приведенная запись недопустима.
<a name=”outer-anchor” href=”next-outer.html”> an outer anchor and link <a name=”inner-anchor” href=”next-inner.html”>an inner anchor and link.</a></a>
15.6. Якоря с атрибутом id
Атрибут id может использоваться для размещения якоря в области начальной метки любого элемента. Ниже приведен пример использования id для размещения якоря в элементе Н2. Якорь подвязан здесь посредством А-элемента.
<h2 id=”section2”>section two</h2>
… позднее в документе …
please refer to <a href=”#section2”>section two</a> above for more details.
Атрибуты ID и name работают в общем пространстве имен (см. ISO10646). Это означает, что они не могут описать якоря с идентичными именами в пределах одного документа.
15.7. Элемент link
<!element link - o empty>
<!attlist link
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| href %url #implied | -- url для подключаемого ресурса -- | |
| rel cdata #implied | -- forward link types -- | |
| rev cdata #implied | -- reverse link types -- | |
| type %contenttype #implied | -- advisory internet content type -- | |
| media cdata #implied | -- для представления в этой среде -- | |
| target cdata #implied | -- место, где производится отображение -- > |
Этот элемент, который должен использоваться в Head-секции документа (любое число раз), определяет связь, независящую от среды.
Хотя Link не имеет содержимого, он предоставляет информацию, обрабатываемую агентами пользователя. Ниже в предлагаемом примере показано как в секции head документа могут появиться несколько определений Link. Атрибуты rel и rev определяют, откуда связь начинается и где кончается.
<html>
<head>
<link rel =”index” href=”../index.html”>
<link rel =”next” href=”chapter_3.html”>
<link rev =”previous” href=”chapter_1.html”>
</head>
……
15.8. Типы связей
Атрибуты rel и rev определяют начало и конец связи, но их значение или значения задают также природу связи. Если для элемента А атрибуты rel и rev не являются обязательными для link, хотя бы один из них присутствовать должен. Агент пользователя может интерпретировать эти атрибуты множеством путей, например, через меню или “клавишу next”. Ниже перечислены некоторые типы связей.
| Содержимое | соединение выполняет функцию оглавления документа. |
| Индекс | соединение предлагает индекс документа. |
| Глоссарий | соединение предлагает глоссарий терминов для данного документа. |
| copyright | соединение воспроизводит заявление о защите авторских прав. |
| Следующий | связь осуществляет переход к следующему документу из списка (next) |
| Предыдущий | связь осуществляет переход к предыдущему документу из списка (previous) |
| Содержание | связь вызывает переход к первому из ряда документов. |
| Справка | связь производит вызов документов, дающих дополнительную информацию по некоторым вопросам (help) |
| Закладка | связь реализует переход в определенную точку документа, часто такой точкой является заголовок главы или раздела (bookmark). |
| Стилевой лист | связь указывает на внешний стилевой лист. |
| Альтернатива | связь указывает на различные версии того же самого документа, например, на переводы данного документа на иностранные языки (alternate). |
15.9. Связи с поисковыми системами
Элемент Link может использоваться для решения задач поиска документов по ключевым словам и другим признакам, например, язык или представления документа в виде, допускающем печать.
Ниже приведен пример, где сообщается поисковой системе о месте нахождения печатной копии руководства.
<head>
<link media=”print” title=”the manual in postscript”
| rel=”alternate” | |
| href=”http://someplace.com/manual/postscript.ps”> |
</head>
А в этом примере мы заставляем поисковую систему найти первую страницу собрания документов.
<head>
<link rel=”start” title=”the first page of the manual”
| href=”html://someplace.com/manual/postscript.ps”> |
</head>
16. Элемент object
<!entity % oalign “(texttop|middltextmiddle|baseline|textbottom|left|center|right)”>
<!element object - - (param | %block)*>
<!attlist object
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| declare (declare) #implied | -- декларирует но не присваивает конкретных значений флагу -- | |
| classid %url #implied | -- идентифицирует приложение -- | |
| codebase %url #implied | -- некоторые системы требуют дополнительного url -- | |
| data %url #implied | -- ссылка на объектные данные -- | |
| type %contenttype #implied | -- Интернетовский тип данных -- | |
| codetype %contenttype #implied | -- Интернетовский тип для кодов -- | |
| standby cdata #implied | -- сообщение, отображаемое при загрузке -- | |
| align %oalign #implied | -- позиционирование в пределах документа -- | |
| height %length #implied | -- предлагаемая высота -- | |
| width %length #implied | -- предлагаемая ширина -- | |
| border %length #implied | -- предлагаемая ширина рамки -- | |
| hspace %length #implied | -- предлагаемый горизонтальный пробел -- | |
| vspace %length #implied | -- предлагаемый вертикальный пробел -- | |
| usemap %url #implied | -- reference to image map -- | |
| shapes (shapes) #implied | -- объект имеет сформированные гипертекстные связи -- | |
| name %url #implied | -- представить, как часть формы -- | |
| tabindex number #implied | -- position in tabbing order -- > |
Определения атрибутов
codebase = url
Этот атрибут специфицирует базовый проход для определения относительного URL, описанного classid.
Если атрибут не задан, значением по умолчанию является базовый URL данного документа.
classid = URL
Этот атрибут специфицирует положение механизма отображения через url.
codetype = cdata
Этот атрибут специфицирует internet media type данных, ожидаемых механизмом отображения, определенным classid. Атрибут является опционным, но рекомендуемым, когда имеется classid, так как это позволяет агенту пользователя избежать загрузки информации для неподдерживаемого типа среды. Если явно величина не задана, его значение по умолчанию соответствует значению атрибута type.
data = URL
Этот атрибут специфицирует положение данных, которые должны быть отображены.
type = cdata
Этот атрибут специфицирует Internet media type для данных, заданных атрибутом data. Атрибут является опционным, но рекомендуемым, когда задан атрибут data, так как это позволяет агенту пользователя избежать загрузки информации с типом, неподдерживаемым средой.
declare
Если присутствует, этот булев атрибут делает текущее определение object лишь декларацией.
standby = cdata
Этот атрибут специфицирует сообщение, которое агент пользователя может отобразить при загрузке объектных приложений и данных.
align = texttop|middle|textmiddle|baseline|textbottom|left|center|right
Не рекомендуется к использованию. Этот атрибут специфицирует положение объекта по отношению к окружающему контексту.
Большинство агентов пользователей снабжены механизмом для отображения базовых типов информации, таких как текст, картинки в GIF-формате, цвета, шрифты и т.д. В HTML элемент object определяет положение механизма отображения и положение данных, необходимых для механизма отображения. Агент пользователя интерпретирует элемент object согласно следующим правилам.
Агент пользователя должен сначала попробовать механизм отображения, заданный атрибутом элемента. Если агент пользователя не может поддержать этот механизм по какой-либо причине, он должен попытаться работать с содержимым элемента.
Важным следствием конструкции элемента object является то, что он предлагает механизм для описания альтернативного механизма отображения различных объектов.
Каждая декларация object может предлагать альтернативный механизм отображения. Если агент пользователя не может воспользоваться имеющимся механизмом, он может обратиться к тексту, который может представлять собой другой элемент object. В ниже приведенном примере использовано несколько деклараций object для иллюстрации альтернативных способов отображения. Агент пользователя сначала попробует отобразить первый элемент object, а далее будет пытаться воспользоваться: аплетом eath, написанным на языке python, mpeg анимацией, изображением земли в формате GIF и, наконец, альтернативным текстом.
<object title=”the earth as seen from space”
classid=”http://www.observer.mars/theearth.py”>
<object data=”theearth.mpeg” type=”application/mpeg”>
| <object src=”theearth.gif”> |
the <strong> ”earth"</strong> as seen from space.
| </object> | ||
| </object> |
</object>
Самая внешняя декларация специфицирует аплет, который не требует данных или начальных параметров. Вторая декларация специфицирует MPEG-анимацию и не определяет механизм отображения, предполагая, что с этой работой справится агент пользователя. Здесь установлен атрибут type, таким образом, что в случае если агент пользователя не может отобразить MPEG, он может не копировать “theearth.mpeg” из сети. Третья декларация специфицирует позицию GIF-файла и предлагает альтернативный текст на случай, когда другие механизмы не приведут к успеху.
Отображаемая информация может извлекаться двумя путями: из текущей строки илиb из внешнего источника. Первый способ дает большее быстродействие, но требует много места.
16.1. Инициализация объекта. Элемент param.
| <!element param - empty | -- именованное значение параметра -- > | |
| <!attlist param name cdata #required | -- имя параметра -- | |
| value cdata #implied | -- значение параметра -- | |
| valuetype (data|ref|object) data | -- способ интерпретации значения -- | |
| type cdata #implied | -- internet media type -- > |
Определения атрибутов
name = cdata
| Этот атрибут определяет имя параметра исполнения. |
value = cdata
Этот атрибут специфицирует значение параметра исполнения, заданного атрибутом name. Значение этого параметра не имеет какого-либо смысла для HTML, он определяется рассматриваемым объектом.
valuetype=data|ref|object
Этот атрибут специфицирует тип значения, определенного атрибутом value. Возможны значения:
| data: | значение, заданное value, после преобразования любых вложенных символов и цифровых объектов будет непосредственно передано механизму отображения в виде строки. Этот тип используется по умолчанию и может появляться в стартовой метке элемента. |
| ref: | значение, заданное value, является url, который определяет ресурс, где записано значение параметра исполнения. URL должно передаваться механизму отображения в не преобразованном виде. |
| object: | значение, заданное value, является фрагментом URL, который определяет декларацию object в том же самом документе. В этом случае определение object должно идентифицироваться его атрибутом ID. |
type = cdata
Этот атрибут специфицирует internet media type ресурса, определенного атрибутом value, только в случае, когда атрибут valuetype = “ref”. Этот атрибут, таким образом, специфицирует для агента пользователя тип значений, которые будут обнаружены в URL, определенном атрибутом value.
Элемент param специфицирует набор значений, которые могут требоваться механизму отображения. В начале декларации object может появиться любое число элементов param. Синтаксис имен и значений предполагается понятным механизму отображения. Имена и значения передаются механизму отображения, как стандартный ввод. Рассмотрим пример. Здесь предполагается, что механизм отображения может воспринять два параметра, которые определяют начальную высоту и ширину (часов). Задаем эти начальные параметры равными 40х40 пикселей.
<object classid=”http://www.miamachina.it/ahalogclock.py”>
<param name=”height” value=”40” valuetype=”data”>
<param name=”width” value=”40” valuetype=”data”>
Этот агент пользователя не может исполнять приложения, написанные на языке python.
</object>
Так как значение по умолчанию valurtype для элемента param равно “data”, мы можем заменить вышеприведенную декларацию следующей:
<param name=”height” value=”40”>
<param name=”width” value=”40”>
или
<param name=”height” value=”40” data>
<param name=”width” value=”40” data>
В следующем исходные данные исполнения для параметра механизма отображения “init_values” заданы как внешний ресурс (GIF-файл). Значение атрибута valuetype установлено равным “ref”, а атрибут value равен URL.
<object classid=”html://www.gifstuff.com/gifappli” standby=”loading elvis…”>
<param name=”init_values” value=”./images/elvis.gif”>
</object>
Здесь установлен также атрибут standby так, что агент пользователя может отобразить сообщение в процессе загрузки механизма отображения. Механизмы отображения локализуются с помощью URL. Первая секция абсолютного URL характеризует протокол, используемый для передачи данных, которые указаны в URL. Для HTML-документов протокол обозначается как HTTP. Но возможны и другие варианты, например, в случае использования механизма отображения java вы можете использовать URL, начинающиеся со слова Java, а для аплетов activex – “clsid”. В предлагаемом примере в HTML-документ введен Java-аплет.
<object classid=”java:program.start”>
</object>
Некоторые схемы отображения требуют дополнительной информации для идентификации их применения и должны сообщить, где можно найти эту информацию. Проход к этой информации для механизма отображения может быть указан с помощью атрибута codebase.
<object codetype=”application/octet-strim” classid=”java:program.start”>
codebase=http://fooo.bar.com/java/myimplement/
</object>
В следующем примере с помощью атрибута classid через URL, который начинается с протокольной информации “clsid”, специфицирован механизм activex.
<object classid=”clsid:663c8fef-1ef9-11cf-a3db-080036f12502”
data=http://www.acme.com/ole/clock.stm>
Это приложение не поддерживается.
</object>
Для декларирования механизма отображения так, чтобы он не запускался в процессе прочтения агентом пользователя, нужно в элементе object установить булеву переменную declare. В то же время вы должны идентифицировать декларацию с помощью атрибута id в элементе object.
В предлагаемом ниже примере декларируется object, который активируется через внешнюю связь. Таким образом, объект можно активировать с помощью мышки, выбрав соответствующий фрагмент текста.
| <object declare | id=”earth_declaration” |
| data=”theearth.mpeg” | |
| type=”application/mpeg”> | |
| <object src=”theearth.gif”> | |
| the <strong>earth</strong> as seen from space. | |
| </object> |
</object>
…далее в документе …
click to see a neat <a href=”#earth_declaration”>
animation of the earth! </a>
Последующий пример иллюстрирует то, как можно специфицировать значения исполнительных параметров, которые являются объектами. В этом примере мы посылаем текст гипотетическому механизму его отображения. Механизм отображения распознает параметр, названный “font”. Значение этого параметра само является объектом, который управляет использованием определенного шрифта. Взаимоотношение этого объекта и механизма отображения устанавливается путем присвоения id “tribune” декларации объекта шрифта и обращением к нему из элемента param.
| <object declare | id=”tribune” |
| type=”application/x-webfont” | |
| data=”tribune.gif”> |
</object>
… здесь отображается текст из файла kublakhan.txt …
<object classid=http://foo.bar.com/poem_viewer
| data=”kublakhan.txt”> |
<param name=”font” valuetype=”object” value=”#tribune”>
<p>you’re missing a really cool poem viewer …
</object>
Агент пользователя, который не поддерживает атрибут declare, должен пытаться отображать содержимое декларации object.
Выравнивание объектов
Атрибут align для данного элемента применять не рекомендуется, предпочтительнее использование стилевых листов.
17. Изображения. Элемент img
| <!element img - o empty | -- введение изображения в текст документа -- > | |
| <!attlist img %attrs; | -- %coreattrs, %i18n, %events -- | |
| src %url #required | -- url вводимого рисунка -- | |
| alt cdata #implied | -- описание для чисто текстовых броузеров -- | |
| align %ialign #implied | -- вертикальное или горизонтальное выравнивание -- | |
| height %pixels #implied | -- предлагаемая высота в пикселях -- | |
| width %pixels #implied | -- предлагаемая ширина в пикселях -- | |
| border %pixels #implied | -- предлагаемая толщина рамки в пикселях -- | |
| hspace %pixels #implied | -- предлагаемая ширина горизонтального поля -- | |
| vspace %pixels #implied | -- предлагаемая ширина вертикального поля -- | |
| usemap %url #implied | -- use client-side image map -- | |
| ismap (ismap) #implied | -- use server-side image map -- |
Определение атрибутов
src = URL
Этот атрибут специфицирует положение (указатель на) ресурса, содержащего изображение. Общепринятые форматы: GIF, JPG, PNG.
align = bottomiddle|top|left|right
Применение не рекомендуется. Атрибуты определяют положение изображения по отношению к окружающему тексту.
Элемент IMG вводит изображение в текущий документ в точке его описания. Но тем не менее, рекомендуется вводить рисунок в текст с помощью элемента object. Рассмотрим, как семейное фото может быть включено в документ.
<img src=”html://www.somecompany.com/people/ian/vocation/family.png”
| alt=”a photo of my family at the lake.”> |
Это же может быть сделано с помощью object следующим образом.
<object data=http://www.somecompany.com/people/ian/vocation/family.png
| type=”image/png”> |
Фото моей семьи на озере.
</object>
Атрибут alt специфицирует текст, который будет выведен в случае, когда изображение не может быть отображено по какой-либо причине.
18. Введение аплетов. Элемент applet
<!element applet - - (param | %inline) *>
<!attlist applet
| codebase %url #implied | -- опционный базовый url для аплета -- | |
| archive cdata #implied | -- архивный список с элементами, разделенными с помощью запятых -- | |
| code cdata #implied | -- файл класса аплета -- | |
| object cdata #implied | -- специализированный файл аплета -- | |
| alt cdata #implied | -- описание для чисто текстовых броузеров -- | |
| name cdata #implied | -- позволяет аплетам найти друг друга -- | |
| width %pixels #required | -- предлагаемая ширина в пикселях -- | |
| height %pixels #required | -- предлагаемая высота в пикселях -- | |
| align %ialign #implied | -- вертикальное или горизонтальное выравнивание -- | |
| hspace %pixels #implied | -- предлагаемые горизонтальные поля -- | |
| vspace %pixels #implied | -- предлагаемые вертикальные поля -- > |
Описания атрибутов
codebase = URL
Этот атрибут специфицирует базовый URL для аплета. Если этот атрибут отсутствует, в качестве базового URL рассматривается текущий документ.
code = cdata
Этот атрибут специфицирует имя ресурса, который содержит откомпилированный субкласс аплета. Значение атрибута должно представлять собой относительный URL по отношению к базовому URL.
name = cdata
Этот атрибут специфицирует имя аплета, которое позволяет аплетам найти друг друга в пределах страницы.
width = length
Этот атрибут специфицирует исходную ширину для области отображения аплета (без учета размера окна или области диалоговых обменов, которые вызывают аплет).
height = length
Этот атрибут специфицирует исходную высоту для области отображения аплета.
align = top|middle|bottom|left|right
Этот атрибут специфицирует положение объекта по отношению к окружающему тексту.
archive = cdata
Этот атрибут специфицирует имена одного или нескольких архивов, разделенные запятыми, содержащие классы и другие ресурсы, которые будут предварительно загружены. Классы загружаются с помощью вызова appletclassloader с данным codebase. Предзагрузка ресурсов может значительно улучшить работу аплета.
object = cdata
Этот атрибут присваивает имя ресурсу, который содержит последовательное представление аплета. Аплет приводится к стандартному виду. Используется метод start().
Этот элемент, поддерживаемый всеми java-броузерами, позволяет разработчикам встраивать Java-аплеты в HTML-документы. Содержимое аплетов используется агентом пользователя как альтернатива, если он не поддерживает данный элемент. При прочих условиях его содержимое должно игнорироваться. Ниже приведен пример Java-аплета.
<applet code=”bubbles.class” width=”500” height=”500”>
java-аплет, который рисует движущиеся пузыри.
</applet>
Эту запись можно переписать в другой форме.
<object codetype=”application/octet-stream”
classid=”java:bubbles.class”
| width=”500” height=”500”> |
java-аплет, который рисует движущиеся пузыри.
</object
Исходные данные можно передать аплету через элемент param
<applet code=”audioitem” width=”15” height=”15”>
<param name=”snd” value=”hello.au|welcome.au”>
java-аплет, который исполняет приветственную мелодию.
</applet>
Вариант, базирующийся на object, представлен ниже.
<object codetype=”application/octet-stream”
classid=”audioitem”
width=”15” height=”15”>
<param name=”snd” value=”hello.au|welcome.au”>
java-аплет, который исполняет приветственную мелодию.
</object>
19. Введение HTML-документа в другой HTML-документ
Иногда возникает необходимость не связи с другим HTML-документом, а полного его включения в текст. Для решения такой задачи рекомендуется использовать элемент object с атрибутом data. Ниже следующая строка включит содержимое file_to_include.html в позицию документа, где размещен элемент object.
<object data=”file_to_include.html”>
warning: file_to_include.html could not be included.
</object>
Содержание object отображается только в случае, когда атрибут data не может быть загружен. При использовании операций включения следует проявлять осторожность, так как файл может содержать элементы, которые вызовут непредсказуемые действия.
Для введения определенного текста в документ можно также использовать элемент Iframe.
20. Введение карты изображения в html-документ
Использование карты изображения позволяет разработчику специфицировать активные зоны изображения и поставить им в соответствие определенные операции. Карта изображения создается путем установления связи между объектом и определенными областями изображения. Существует два типа карт изображения:
Сторона сервера. Когда пользователь активирует область карты изображения со стороны сервера с помощью мышки, координаты нажатия клавиши посылаются серверу, где помещен документ. Сервер интерпретирует эти координаты и выполняет определенные действия (определено атрибутом href элемента А).
Сторона клиента. Когда пользователь активирует область карты изображения со стороны клиента с помощью мышки, координаты нажатия клавиши интерпретируются агентом пользователя. Агент пользователя выбирает связь, которая была специфицирована для активированной области.
Предпочтительной считается карта изображения клиента. Предусматривается возможность использования карты изображения несколькими элементами.
20.1. Карты изображения клиента
Ниже описаны атрибуты элементов A и AREA, которые позволяют разработчику специфицировать ряд геометрических областей и ассоциировать их с определенными URL.
Описания атрибутов
shape = default|rect|circle|poly
Этот атрибут специфицирует форму области. Возможные значения:
| default | специфицирует всю область. | |
| rect | выделяет прямоугольную область. | |
| circle | выделяет круговую область. | |
| poly | выделяет область, ограниченную многогранником. |
coords = length-list
Этот атрибут специфицирует положение и форму области на экране. Число и порядок значений зависит от определенной формы. Возможны комбинации:
| rect: | левый-х, верхний-у, правый-х, нижний-у. | |
| circle: | х центра, у центра, радиус. | |
| poly: | х1, у1, х2, у2,…хn, yn. |
Начало координат размещено в верхнем левом углу объекта. Значения координат выражаются в пикселях или в процентах.
Для элемента object описан также булев атрибут shapes, который определяет то, что объект является картой изображения. Ниже представлен пример с картой изображения клиента.
<object data=:navbar.gif” shapes>
<a href=”guide.html” shape=”rect” coords=”0,0,118,28”>access guide</a> |
<a href=”shotcut.html” shape=”rect” coords=”118,0,184,28”>go</a> |
<a href=”search.html” shape=”circ” coords=”184,200,60”>search</a> |
<a href=”top10.html” shape=”poly” coords=”276,0,373,28,50,50,276,0”>top ten</a>
</object>
Если элемент object содержит атрибут shapes, агент пользователя должен анализировать содержимое элемента с целью поиска якорей. Если две или более областей перекрываются, область, определенная первой, имеет приоритет.
20.2. Карты изображения клиента с map и area
Элементы map и area предоставляют альтернативный механизм для карт изображения клиента.
<!element map - - (area)*>
| <!attrlist map %coreattrs; | -- id, class, style, title -- |
| name cdata #implied > |
<!element area – o empty>
<!attrlist area
| shape %shape rect | -- контролирует интерпретацию координат -- | |
| coords %coords #implied | -- список значений, разделенных запятыми -- | |
| href %url #implied | -- эта область используется как гипертекстная связь -- | |
| target cdata #implied | -- где отображать подключенный ресурс -- | |
| nohref (nohref) #implied | -- эта область не вызывает никаких действий -- | |
| alt cdata #implied | -- описание для исключительно текстовых броузеров -- | |
| tabindex number #implied | -- position in tabbing order -- > |
Определение атрибута
| nohref | Этот булев атрибут (если =true) указывает на то, что данная область не имеет никаких связей. |
Несколько элементов (object, img и input) имеют атрибут usemap = URL для спецификации карты изображения клиента описанной элементами map и area.
Рассмотрим пример, представленный выше, переписанный в терминах MAP и AREA.
<object data=:navbar1.gif” usemap=”#map></object>
<map name=”map1”>
| <area href=”guide.html” | ||
| alt=”search” | ||
| shape=”rect” | ||
| coords=”184,0,276,28”> |
<area href=”top10.html”
| alt=”top ten” | |
| shape=”poly” | |
| coords=”276,0,373,28,50,50,276,0”> |
</map>
Атрибут alt специфицирует альтернативный текст на случай, когда карта изображения не может быть отображена. map не совместима с версией HTML 2.0.
Карты изображения сервера
Карты изображения сервера могут представлять интерес в случае, когда карта изображения слишком сложна для стороны клиента. Такая карта может быть создана с помощью элемента img. Для того чтобы сделать это, нужно установить булев атрибут ismap в описании элемента IMG. Соответствующие области должны быть описаны с помощью атрибута usemap. Когда пользователь активирует область карты изображения, соответствующие координаты посылаются непосредственно серверу, где помещен документ. Координаты на экране выражаются в пикселях. Агент пользователя берет новый URL из URL, описанного атрибутом HREF, присоединив к нему символ “?”, за которым следуют координаты х и у, разделенные запятой. Например, в предыдущем примере, если пользователь кликнет в области x=10, y=27, то будет получен URL=/cgibin/navbar.map?10,27.
В следующем примере первая активная область определяет связь со стороны клиента. Вторая - определяет связь со стороны сервера, но не определяет ее форму и размер (это осуществляется значением по умолчанию атрибута shape). Так как области этих связей перекрываются, первая имеет более высокий приоритет. Таким образом, кликнув мышкой где-либо в прямоугольной области, мы пошлем соответствующие координаты серверу.
<object data=”game.gif” shapes>
| <a href=”guide.html” shape=”rect” coords=”0,0,118,28”> | ||
| rules of the game </a> | ||
| <a href=http://www.acme.com/cgi-bin/competition | ||
| ismap | ||
| shape=”default”> | ||
| guess the location </a> |
</object>
21. Визуальное представление изображений, объектов и аплетов
Применение атрибутов элементов img и object для целей управления отображением не рекомендуется, предпочтение, как и раньше здесь отдается стилевым листам.
Атрибуты height и width дают агенту пользователя информацию о размере изображения или объекта, что позволяет зарезервировать для него место, а тем временем продолжить отображение документа. Оба атрибута могут иметь значение типа length. Агент пользователя может изменить масштаб, если это необходимо. Атрибуты vspace и hspace специфицируют размер полей вокруг изображения или объекта. Значения по умолчанию этих атрибутов не определено, оно должно быть мало, но не равно нулю.
22. Как специфицировать альтернативный текст?
Описание атрибута
alt = cdata
Для агента пользователя, который не может отображать изображения, формы или аплеты, этот атрибут позволяет ввести альтернативный текст. Язык этого текста задается атрибутом lang. Атрибут alt является обязательным для элемента area и опционным для img, applet и input.
23. Стилевые листы
Стилевые листы являются главным инструментом при разработке дизайна HTML-страниц. Они дают разработчику возможность преобразовать текст в изображение, отображать таблицы, писать программы и делать многое другое. HTML 4.0 поддерживает следующие возможности:
Гибкое размещение стилевой информации. Помещение стилевых листов в отдельные файлы упрощает их повторное использование.
Независимость от стилевых особенностей используемого языка. Данная спецификация HTML не привязывает его к какому-то определенному языку.
Каскадирование стилевых листов. Эта особенность позволяет совместно использовать стилевую информацию из нескольких источников.
Зависимость от среды. HTML позволяет описать документ независимым от среды способом, что обеспечивает доступ широкому кругу людей, работающих в различных средах (Windows, X11, Mac, мультимедиа системы и пр.). Стилевые листы позволяют адаптироваться к среде наилучшим образом, используя все предоставляемые ей возможности.
Альтернативные стили. Разработчик может предложить пользователю несколько альтернативных стилей представления данных. Например, отображение с мелкими или крупными шрифтами, с или без графических объектов и т.д.
HTML- документ может содержать стилевые рекомендации внутри, но можно их импортировать и извне. Синтаксис стилевых правил определяется языком стилевых листов CSS (Cascading Style Sheets), который не является частью HTML. Так как агент пользователя должен осуществлять разбор стилевых инструкций, пользователь обязан декларировать, какой стилевой язык он использует. Можно использовать элемент META для установки стилевого языка по умолчанию. Так для установления в качестве стилевого языка по умолчанию CSS, в head документа нужно включить следующую декларацию.
<meta http-equiv=”content-style-type” content=”text/css”>
Стилевой язык может быть задан также в http-заголовках. Например:
content-style-type: text/css
Если использовано несколько деклараций стилевого языка, работает самая последняя декларация. Если нет явной декларации стилевого языка, по умолчанию устанавливается CSS. HTML-элементы и атрибуты определяют начало стилевого листа. Конец стилевого листа определяется открытым разграничителем конечной метки, за которым следует начальный символ имени SGML [a-za-z]. Агент пользователя должен иметь соответствующий хандлер стилевого листа.
Одним из строчных стилевых атрибутов является style = Cdata. Этот атрибут специфицирует стилевую информацию для текущего элемента. Ниже приведен пример задания цвета и размера шрифта в тексте параграфа.
<p type=”text/css” style=”font-size: 12pt; color: fuschia”>aren’t style sheet wonderful?
Декларация типа имя: значение является конструкцией языка CSS. Если стиль планируется использовать повторно в нескольких элементах, более корректным будет применение элемента style, а не атрибута style, который носит одноразовый характер.
23.1. Стилевая информация заголовка. Элемент style
<!element style - - cdata -- стилевая информация --
<!attlist style
| %i18n; | -- lang, dir, для использования с title -- | |
| type cdata #implied | -- тип содержимого internet для стилевого языка -- | |
| media cdata #implied | -- предназначено для использования в этих средах -- | |
| title cdata #implied | -- рекомендуемый title -- > |
Описание атрибутов
type = cdata
Этот атрибут специфицирует язык стилевого листа (заменяет значение по умолчанию). Стилевой язык специфицируется также как и тип среды Интернет (internet media type) (т.е. “text/css”).
media cdata-list
Этот атрибут специфицирует среду для стилевой информации. Это может быть одна среда или перечень, где отдельные элементы списка разделены запятыми. Возможные типы сред:
| screen: | Вывод на экран дисплей (без многостраничной поддержки). Значение по умолчанию. | |
| print: | Постраничный вывод на непрозрачную бумагу. Предназначен также для вывода на экран в режиме preview. | |
| projection: | Вывод на проектор. | |
| braille: | Вывод кодов Брайля на тактильное устройство | |
| speach: | Вывод на речевой синтезатор. | |
| all: | Вывод на все устройства сразу. |
Элемент style позволяет разработчику установить стилевые правила в заголовке документа. HTML допускает любое число элементов style в секции head документа. Агент пользователя, который не поддерживает стилевые листы или специфический стилевой язык, используемый элементом style, должен прятать содержимое элемента style. Управление средой особенно интересно, когда применяются внешние стилевые листы, так как агент пользователя может сэкономить время, копируя через сеть только те стилевые листы, которые используются на данном устройстве вывода.
Следующая декларация CSS style устанавливает рамку вокруг каждого Н1 элемента в документе и центрирует ее на странице.
<head>
<style type=”text/css”>
| h1 {border-width: 1; border: solid; text-align: center} | ||
| </style> |
</head>
Для спецификации того, что этот стиль информации должен применяться только для Н1-элементов определенного класса, модифицируем эту запись следующим образом.
<head>
<style type=”text/css”>
| h1.myclass {border-width: 1; border: solid; text-align: center} | ||
| </style> |
</head>
<body>
| <h1 class=”myclass”> this H1 is affected by our style </h1> | |
| <h1 this one is not affected by our style </h1> |
</body>
И наконец, для того чтобы ограничить зону действия стилевой информации одним случаем Н1, установим атрибут ID.
<head>
| <style type=”text/css”> | ||
| h1.myid {border-width: 1; border: solid; text-align: center} | ||
| </style> |
</head>
<body>
| <H1 class=”myclass”> this H1 is not affected </h1> | |
| <H1 this one is affected by style </H1> | |
| <H1> this h1 is not affected </H1> |
</body>
В следующем примере использован элемент span для определения шрифтового стиля первых нескольких слов.
<head>
| <style type=”text/css”> | ||
| span.sc-ex { font-variant: small-caps } | ||
| </style> |
</head>
<body>
| <p><span id=”sc-ex”> the first</span> few words of | ||
| this paragraph are in small-caps |
</body>
В следующем примере используется div и атрибут class для выравнивания последовательности параграфов. Эта стилевая информация может быть использована повторно, например, для форматирования резюме научных статей путем установки атрибута class в соответствующем месте документа.
<head>
| <style type=”text/css”> | ||
| div.abstact {text-align: justify } | ||
| </style> |
</head>
<body>
| <div class=”abstract”> | |
| <p>the chieftain product range is our market winner for the coming year. | |
| this report sets out how to position chieftain against competing products. | |
| <p>chieftain replaces the commander range, which will remain on the | |
| price list until further notice. |
</div>
</body>
23.2. Типы среды
HTML позволяет разработчику конструировать документы, структура которых не зависит от специфических свойств среды. В результате пользователь может просматривать этот документ с использованием самых разных агентов пользователя: на персональной ЭВМ, рабочей станции, Х-терминале, специально приспособленном телефонном аппарате и т.д..
Атрибут media специфицирует среду вывода для формирования стилевых правил.
Установив атрибут media, разработчик может позволить агенту пользователя избежать копирования через сеть стилевых листов, не используемых в данном документе. Ниже предлагается пример деклараций для элемента Н1. При отображении на экране текст будет голубым и выровненным по центру, при печати текст будет выровнен по центру. Предусмотрена возможность вывода и на речевой синтезатор.
<head>
| <style type=”text/css” media=”screen”> | ||
| h1 { color: blue } | ||
| </style> |
<style type=”text/css” media=”screen, print”>
h1 { text-align: center }
</style>
<style type=”text/acss” media=”speach”>
h1 { cue-before: url(bell.aiff); cue-after: url(dong.wav)}
</style>
</head>
Предыдущий пример может быть переписан для случая применения внешних стилевых листов (вместо элемента style) в сочетании с атрибутом media. Агент пользователя на основе атрибута media принимает решение о копировании из сети тех или иных стилевых листов.
<head>
<link href=”docl-screen.css” rel=”stylesheet”
| type=”text/css” media=”screen”> |
<link href=”docl-print.css” rel=”stylesheet”
| type=”text/css” media=”print”> |
<link href=”docl-speach.css” rel=”stylesheet”
| type=”text/css” media=”speach”> |
</head>
23.3. Внешние стилевые листы
Стилевые листы могут быть определены отдельно от документа. Это позволяет использовать такие стилевые листы во многих документах. Кроме того, стиль может быть изменен без модификации самого документа. Любой стиль обычно представляет собой иерархию стилевых листов. Некоторые из них используются вне зависимости от выбора пользователя. Для выбора внешних стилевых листов используется элемент Link. При этом необходимо установить следующие атрибуты:
| href | для определения места размещения внешнего стилевого файла (href=url). |
| rel | определяет, является ли данный стилевой лист постоянным (rel=”stylesheet”), стилевым листом по умолчанию (rel=”stylesheet”) или листом по выбору (rel=”alternate stylesheet”). |
| title | устанавливает заголовок в случае, когда стилевой лист является листом по умолчанию (активируется и деактивируется пользователем). |
Сначала специфицируются постоянные (persistent) внешние стилевые листы (например, из файла mystyle.css).
<link href=”mystyle/css” rel=”stylesheet”>
Установка атрибута title превращает постоянный стилевой лист в лист по умолчанию. Агенты пользователя должны предоставлять возможность применения именованных стилей на базе атрибута title.
<link href=”mystyle/css” title=”compact” rel=”stylesheet”>
Добавление ключевого слова “alternate” к атрибуту rel делает стилевой лист альтернативным.
<link href=”mystyle/css” title=”medium” rel=”alternate stylesheet”>
Все альтернативные стили, имеющие один и тот же заголовок (title), будут использоваться, когда пользователь (через агента пользователя) активирует этот стиль. Стилевые листы с разными заголовками в этом случае не будут применены. Однако, стилевые листы, которые не имеют атрибута title, применяются всегда (за исключением случая, когда пользователь отключает все стилевые листы).
Агент пользователя должен обеспечить средства выбора стилей для пользователей. Значение атрибута title предоставляет имя, которое может использоваться при выборе стиля. В предлагаемом примере определено два альтернативных стиля, названных “compact”. Если пользователь выберет стиль “compact”, будут применены оба внешних стилевых листа, а также стилевой лист “common.css” (применяется всегда, так как атрибут title не установлен). Если пользователь выберет стиль “big print”, агент пользователя применит файлы “bigprint.css” и “common.css”.
<link rel=”alternate stylesheet” title=”compact” href=”small-base.css”>
<link rel=”alternate stylesheet” title=”compact” href=”small-extras.css”>
<link rel=”alternate stylesheet” title=”big- print” href=”bigprint.css”>
<link rel=stylesheet href=”common.css”>
Ниже предлагается вариант с элементами link и style.
<link rel=stylesheet href=”corporate.css”>
<link rel=stylesheet href=”techreport.css”>
<style type=”text/css”>
| p.special { color: rgb(230, 100, 180) } |
</style>
23.4. Установка именованного стиля по умолчанию
Для установки в документе именованного стиля по умолчанию используется элемент meta. Например (установка стилевого листа “compact” в качестве стиля по умолчанию):
<meta http-equiv=”default-style” content=”compact”
Стилевой лист по умолчанию может быть установлен в HTML-заголовке.
default-style: “compact”
Если имеется две или более деклараций стилевого листа по умолчанию, то работает последняя декларация. Если явной декларации стиля по умолчанию нет, то берется первый элемент link, где есть title и где имеется атрибут rel=”stylesheet”.
При отображении документа с использованием стилевых листов выполняются определенные правила наследования свойств (тип шрифта, цвет и т.д.). Если то или иное свойство не может быть наследовано, используется значение по умолчанию.
Некоторые стилевые языки поддерживают синтаксис, который позволяет разработчику спрятать содержимое элементов style от агентов пользователя, которые их не поддерживают, с тем, чтобы они не пытались отобразить эти фрагменты, как текст. Например (случай с CSS):
<style type=”text/css”>
<!-- h1 { color: red }
p { color: blue} -->
</style
Иногда бывает удобно, конфигурируя WEB-сервер, установить стилевые листы, которые воздействуют на группу WWW-страниц. HTTP Link-заголовок имеет то же воздействие, что и элемент Link с теми же атрибутами и значениями. Заголовки с несколькими Link работают также как и несколько элементов Link, в соответствии с их порядком записи.
link: rel=stylesheet href=”corporate.css”
cоответствует
<link rel=”stylesheet” href=”corporate.css”>
Можно описать несколько альтернативных стилей, используя несколько Link-заголовков, а затем с помощью атрибута Rel определить стиль по умолчанию.
link: rel=”stylesheet” title=”compact” href=”compact.css”
link: rel=”alrernate stylesheet” title=”big print” href=”bigprint.css”
23.5. Форматирование
Для задания цвета фона может использоваться атрибут bgcolor = color (хотя это и не рекомендуется).
Применение стилевых листов для решения этой задачи предпочтительнее.
Другой проблемой форматирования является выравнивание текста. Для этой цели служит атрибут Align = left|center|right|justify. Здесь справедливы те же замечания, что и в случае атрибута bgcolor. Ниже предлагается пример решения задачи выравнивания с использованием стилевого листа.
<head>
<style>
h1 { test-align: center }
</style>
</head>
<h1> how to carve wood </h1>
Следует иметь в виду, что приведенный текст отцентрирует все заголовки Н1. Можно ограничить зону действия данного стиля, установив атрибут ID.
<head>
<style type=”text/css”>
h1.wood {text-align: center}
</style>
</head>
<h1 id=”wood”> how to carve wood </h1>
Аналогично для выравнивания по правому и левому полям с использование атрибута align:
<p align=”justify”> ….далее следует текст….
То же с использованием стилевого листа:
<head>
<style type=”text/css”>
p.mypar {text-align: justify}
</style>
</head>
<p id=”mypar”> ….далее следует текст….
Для двойного выравнивания последовательности параграфов можно группировать их с помощью элемента div.
<div align=”justify”>
<p> … текст первого параграфа….
<p> … текст второго параграфа….
<p> … текст третьего параграфа….
</div>
Решение той же задачи с использованием каскадирования стилевых листов:
<head>
<style type=”text/css”>
div.mypars {text-align: justify}
</style>
</head>
<div id=”mypars”>
<p> … текст первого параграфа….
<p> … текст второго параграфа….
<p> … текст третьего параграфа….
</div>
Для выравнивания всего документа с использованием каскадирования стилевых листов можно записать:
<head>
<style type=”text/css”>
body {text-align: justify}
</style>
</head>
<body>
… текст документа, подлежащий выравниванию …
</body>
Элемент center работает также как и элемент div с атрибутом align=”center”. Использование center не рекомендуется.
23.6. Плавающие объекты
Изображения и объекты могут быть привязаны к тексту, а могут обтекаться текстом, прижимаясь к одной из сторон документа и деформируя его поля. Плавающие объекты начинаются с новой строки. Для управления положением плавающего объекта используется атрибут align. Например:
<img align=”left” src=http://foo.com/animage.gif>
Существует атрибут для элемента br, который управляет обтеканием объекта текстом. Это clear= none|left|right|all, который определяет то, где должна появиться следующая строка в процессе отображения.
| none | следующая строка будет отображена как обычно (значение по умолчанию). |
| left | следующая строка будет помещена ниже плавающего объекта на левом поле. |
| right | следующая строка будет помещена ниже плавающего объекта на правом поле. |
| all | следующая строка будет помещена ниже плавающего объекта на любом из доступных полей. |
Рассмотрим вариант, когда текст размещается справа от изображения, и посмотрим, что будет после прерывания строки с помощью BR.
Если атрибут clear=”none”, следующая строка начнется сразу под уже имеющимся текстом.
Если же clear = “left” или all, то мы получим:
Используя стилевые листы, мы можем потребовать, чтобы все разрывы строк обрабатывались аналогичным образом. Для реализации этого можно записать:
<style type=”text/css”>
br { clear: left }
</style>
Для того чтобы такая схема размещения текста сработала только раз, следует воспользоваться атрибутом ID.
<head>
…….
<style type=”text/css”>
br.mybr }clear: left}
</style>
</head>
<body>
……..
</body>
23.7. Элементы управления шрифтами: tt, i, b, big, small, strike, s и u
<!entity % font
“tt | i | b | u | s | strike | big | small “>
<!element (%font|%phrase) - - (%inline)*>
<!attlist (%font|%phrase) %attrs; -- %coreattrs, %i18n, %events -- >
| tt: | соответствует шрифту телетайпа (символы равной ширины). |
| i: | курсив |
| b: | полужирный шрифт. |
| big: | шрифт с крупными буквами. |
| small: | мелкий шрифт. |
| strike: | перечеркнутый шрифт (к использованию не рекомендуется) |
| u: | подчеркнутый шрифт (к использованию не рекомендуется) |
Ниже приведены примеры управления шрифтами.
<b>bold</b>
<i>italic</i>, <b><i>bold italic</i></b>, <tt>teletype text</tt>
<big>big</big> <small> small </small> text.
Броузер отобразит при этом на экране:
bold, italic, bold italic, teletype text, big, small text.
Использование стилевых листов позволяет получить значительно большее многообразие шрифтов. Например, нижеприведенный текст даст распечатку голубым курсивом:
<head>
<style>
p.mypar {font-style: italic; color: blue}
</style>
</head>
<p id=”mypar”> … далее следует текст, печатаемый голубыми буквами курсивом.
23.8. Элементы модификаторов шрифтов: font и basefont
<!element font - - (%inline)* -- локальное изменение шрифта -->
<!attlist font
| size cdata #implied | -- [+]nn напр. size=”+1”, size=4 -- | |
| color cdata #implied | -- #rgbgbb in hex, напр. red: “#ff0000” -- | |
| face cdata #implied | -- список имен шрифтов, разделенных запятыми -- > |
<!element basefont - o empty>
<!attlist basefont
| size cdata #required | -- базовый размер шрифта для элементов font -- | |
| color cdata #implied | -- #rgbgbb in hex, напр. red: “#ff0000” -- | |
| face cdata #implied | -- список имен шрифтов, разделенных запятыми -- > |
С этими элементами могут использоваться атрибуты (все они не рекомендуются к использованию):
size = cdata
Атрибут определяет размер шрифта (1-7).
color = color
Атрибут определяет цвет шрифта.
face = cdata-list
Атрибут определяет список шрифтов, которые агент пользователя должен рассматривать в порядке приоритета.
Элемент font изменяет размер и цвет шрифта для текста, в нем содержащегося. Элемент basefont устанавливает базовый размер шрифта (с помощью атрибута size). Размер шрифта, заданного font является относительным по отношению к размеру, определенному basefont. Если basefont не задан, значением по умолчанию считается 4. Ниже приведены примеры задания шрифтов с помощью font (данная форма определения размера шрифта не рекомендуется).
<p> <font size=1> size=1</font>
<font size=2> size=2</font>
<font size=3> size=3</font>
<font size=4> size=4</font>
<font size=5> size=5</font>
<font size=6> size=6</font>
<font size=7> size=7</font>
Агент пользователя при этом отобразит следующее
size=1 size=2 size=3 size=4 size=5 size=6 size=7
23.9. Элемент hr
<!element hr - o empty>
| <!attlist hr %coreattrs; | -- id, class, style, title -- |
| %events; | |
| align (left|right|center) #implied | |
| () #implied | |
| size %pixels #implied | |
| width %length #implied > |
Определение атрибутов
Этот булев атрибут требует, чтобы агент пользователя пользовался одноцветным способом отображения линии.
size = length
(Не рекомендуется) Этот атрибут определяет высоту линии.
width = length
(Не рекомендуется) Этот атрибут определяет ширину линии (по умолчанию 100%), то есть линия пресекает весь экран.
Пример использования элемента hr.
<hr width=”50%” align=”center”>
<hr size=”5” width=”50%” align=”center”>
<hr size=”5” width=”50%” align=”center”>
24. Рамки (frames)
Обычный документ имеет одну секцию заголовка и одну секцию тела документа. Документ с рамками имеет заголовок (head), frameset (набор рамок) и, опционно, тело документа. Секция frameset специфицирует раскладку объектов в основном окне агента пользователя. Секция body предлагает альтернативу для случая агентов пользователя, которые не поддерживают frameset.
24.1. Элемент frameset
<!element frameset - - ((frameset|frame) + & noframes?)>
<!attlist frameset
| -- абсолютные значения в пикселях, проценты или относительные значения -- | ||
| rows cdata #implied | -- если не задано, по умолчанию rows=1 -- | |
| cols cdata #implied | -- если не задано, по умолчанию cols=1 -- | |
| onload %script #implied | -- все рамки загружены -- | |
| onunload %script #implied | -- все рамки удалены -- > |
Определения атрибутов
rows = length-list
Этот атрибут специфицирует выкладку горизонтальных рамок. Значение представляет собой список длин, разделенных запятыми. Если атрибут не задан, значение по умолчанию равно 100%.
cols = length-list
Этот атрибут специфицирует выкладку вертикальных рамок. Значение представляет собой список длин, разделенных запятыми. Если атрибут не задан, значение по умолчанию равно 100%.
Все рамки предполагаются прямоугольными. Установка атрибута rows определяет число рамок по горизонтали, а атрибут cols задает число рамок по вертикали. Таким образом, задается сетка рамок. Если атрибут rows не задан, каждая колонка занимает всю длину страницы. Если атрибут cols не задан, каждый ряд занимает всю ширину страницы. Если не заданы оба атрибута, на странице присутствует одна рамка, занимающая всю страницу.
Размер может задаваться в пикселях (абсолютно), в процентах от размеров экрана или в относительных длинах в форме i*, где i – целое число. Когда заданы оба атрибута, агент пользователя сначала выделяет размеры, заданные абсолютно, затем оставшуюся часть делит в соответствии с определенными долями. Значение * эквивалентно 1*. Отображение страницы осуществляется слева направо и сверху вниз. Пример (экран делится на две равные части, верхнюю и нижнюю):
<frameset rows=”50%, 50%”>
… остальная часть определения …
</frameset>
В следующем примере создается три колонки: вторая имеет фиксированную ширину в 250 пикселей (что удобно для картинки известного размера). Первая получает 25% оставшегося пространства, а третья – 75%.
<frameset cols=”1*,250,3*”>
… остальная часть определения …
</frameset>
В следующем примере создается решетка 2х3
<frameset rows=”30%,70%” cols=”33%,34%,33%”>
… остальная часть определения …
</frameset>
В следующем примере предполагается, что высота окна равна 1000 пикселей. Для первой рамки выделяется 30% общей высоты (300 пикселей). Для второй рамки выделено точно 400 пикселей. Это оставляет 300 пикселей на две оставшиеся рамки.
Высота четвертой рамки определена как “2*”, а третей - *, следовательно, третья получит 100, а четвертая – 200 пикселей.
<frameset rows=”30%,400,*,2*” >
… остальная часть определения …
</frameset>
Если при задании абсолютных размеров остается свободное место, или возникает перерасход пространства, агент пользователя пропорционально увеличит или уменьшит размеры рамок. frameset могут вкладываться друг в друга на любом уровне. В приведенном примере внешний frameset делит имеющееся пространство на три равные колонки. Внутренний frameset делит вторую область на два ряда не равной высоты.
<frameset rows=”33%,33%,34%” >
…содержимое первой рамки…
| <frameset rows=”40%,50%” > | |
| …содержимое второй рамки первого ряда… | |
| …содержимое второй рамки второго ряда… | |
| </frameset> | |
| …содержимое третей рамки… |
</frameset>
24.2. Элемент frame
<!element frame - o empty>
<!attlist frame
| name cdata #implied | -- имя рамки -- | |
| src %url #implied | -- источник содержимого рамки -- | |
| frameborder (1|0) 1 | -- request frame border? -- | |
| marginwidth %pixels #implied | -- ширина полей в пикселях -- | |
| marginheight %pixels #implied | -- высота полей в пикселях -- | |
| noresize (noresize) #implied | -- позволить пользователям изменять размеры рамок? -- | |
| scrolling (yes/no/auto) auto | -- делать полосу прокрутки или нет? -- > |
Определения атрибутов
name = cdata
Атрибут присваивает имя текущей рамке. К этому имени можно адресоваться.
src = url
Этот атрибут специфицирует положение исходного документа, содержимое которого заключено в рамку.
noresize
Этот булев атрибут говорит агенту пользователя, что размер окна рамки не может быть изменен.
scrolling = auto|yes|no
Этот атрибут специфицирует информацию о возможности прокрутки информации в данной рамке. Возможные значения:
| auto: | говорит агенту пользователя, что он может организовывать скроллинг по своему усмотрению (значение по умолчанию) | |
| yes: | говорит агенту пользователя, что он должен обеспечить скроллинг информации в окне. | |
| no: | говорит агенту пользователя, что скроллинг делать не нужно. |
frameborder=1|0
Этот атрибут предоставляет агенту пользователя информацию о рамке вокруг текущего окошка. 1 означает, что агент пользователя должен прочертить границу вокруг текущей рамки (значение по умолчанию). 0 означает, что агент пользователя не должен прочерчивать границу вокруг текущей рамки.
marginwidth = length
Этот атрибут специфицирует правое и левое поля между текстом и границей рамки. Значение должно быть больше одного пикселя. Значение по умолчанию определяет агент пользователя.
marginheight = length
Этот атрибут специфицирует размер верхнего и нижнего поля между текстом и границей рамки. Значение должно быть больше одного пикселя. Значение по умолчанию определяет агент пользователя.
Атрибут SRC определяет источник текста, помещаемого в рамку. Содержимое рамки не может быть записано в том же документе, в котором описана сама рамка. Пример:
<html>
<frameset cols=”33%, 33%, 33%”>
| <frameset rows=”*,200”> | ||
| <frame src=”contents_of_frame1.html”> | ||
| <frame src=”contents_of_frame2.gif”> | ||
| </frameset> | ||
| <frame> src=”contents_of_frame3.html”> | ||
| <frame> src=”contents_of_frame4.html”> |
</frameset>
</html>
В результате будет получена раскладка рамок, показанная ниже не рисунке.
Ниже приведенный пример содержит в себе ошибку, так как текст второй рамки включен в описание самой рамки.
<html>
<frameset cols=”50%,50%”>
| <frame src=”contents_of_frame1.html”> | |
| <frame src=”#anchor_in_same_document”> |
</frameset>
<body>
… некоторый текст…
<h2><a name=”anchor_in_same_document”>important section</a></h2>
… некоторый текст…
</body>
</html>
Существует атрибут target = cdata, который специфицирует имя рамки, где должна быть размещена информация. Путем присвоения с помощью атрибута name имени рамке разработчик может ссылаться на нее, как на адрес связей. Атрибут target может быть установлен для элементов, создающих связи (А, link), карты изображения (area) и формы (form).
Ниже предлагается пример, где target позволяет динамически изменять содержимое рамки:
<html>
<frameset rows=”50%,50%”>
| <frame name=”fixed” src=”init_fixed.html”> | |
| <frame name=”dynamic” src=”init_dynamic.html”> |
</frameset>
</html>
Затем в init_dynamic.html мы организуем связь с рамкой под именем “dynamic”
<html>
<body >
… начало документа …
now you may advance to
| <a href=”slide2.html” target=”dynamic”>slide 2.</a> |
… продолжение документа …
you’re doing great. now on to
| <a href=”slide3.html” target=”dynamic”>slide 3.</a> |
</body>
</html>
Активирование любой связи приводит к открытию документа в рамке с именем “dynamic”, в то время как другие рамки (“fixed”) остаются со своим исходным содержимым.
24.3. Установка для связей адресов по умолчания
Когда многие связи в документе указывают на один и тот же адрес, имеется возможность специфицировать адрес только один раз, а ссылки обеспечить путем введения атрибута target в нужные элементы. Это делается путем установки атрибута target элемента base. Рассмотрим предыдущий пример с этой точки зрения.
<html>
<head>
<base target=”dynamic”>
</head>
<body>
… начало документа …
now you may advance to <a href=”slide2.html”>slide 2.</a>
… продолжение документа …
you’re doing great. now on to
<a href=”slide3.html”>slide 3.</a>
</head>
</html>
Существует несколько методов сделать рамку адресом связи.
Если элемент имеет атрибут target, указывающий на известную рамку, тогда при активации элемента, документ связанный с этим элементом, будет загружен в данную рамку.
Если элемент не имеет атрибута target и имеет элемент base, тогда именно base определяет рамку, куда будет произведена загрузка.
Если элемент и base не имеют атрибута target, документ, соответствующий элементу, будет загружен в рамку, содержащую этот элемент.
Если любой адрес (target) указывает на рамку f, агент пользователя создаст новое окно и рамку, припишет имя f этой рамке и загрузит документ, соответствующий элементу, в эту новую рамку.
Имя рамки должно начинаться с буквы (a-za-z). Агент пользователя должен игнорировать любые другие имена. Существует несколько имен, зарезервированных для специальных целей.
| _blank | агент пользователя должен загрузить документ в новую безымянную рамку. |
| _self | агент пользователя должен загрузить документ в ту же рамку, что и элемент, который ссылается на этот адрес (target). |
| _parent | агент пользователя должен загрузить документ в frameset, породивший текущую рамку. Это значение эквивалентно _self, если текущая рамка не имеет прародителя. |
| _top | агент пользователя должен загрузить документ в полное исходное окно. Значение эквивалентно _self, если текущее окно не имеет прародителя. |
Агенты пользователя, которые не поддерживают рамки, должны отображать секцию body, которая следует за самым внешним frameset документа. Агенты пользователя, которые поддерживают рамки, должны игнорировать эту секцию body.
24.4. Элемент noframes
<!element noframes - - (#pcdata, ((body,#pcdata)|
| (((%blocklevel)|%font|%phrase|%special|%formctrl),%block)))> |
Элемент noframes специфицирует содержимое, которое должно быть отображено, только когда не отображаются рамки. Агенты пользователя могут отображать содержимое только в случае, когда они сконфигурированы с блокировкой поддержки рамок.
Предположим, что имеется frameset, определенный в “top.html”, который отображает документ “main.html”, и оглавление этого документа (“table_of_contents.html”). Тогда содержимое “top.html”:
<html>
<frameset cols=”50%,50%”>
| <frame src=”main.html”> | |
| <frame src=”table_of_contents.html”> |
</frameset>
</html>
Когда пользователь читает “top.html”, а агент пользователя не поддерживает работу с рамками, на экране ничего не появится, если в секции body (“top.html”) нет альтернативного текста. Если мы введем ”table_of_contents.html” и ”main.html” непосредственно в body, задача ассоциации документов будет решена. Но при этом мы можем заставить агента пользователя, который поддерживает рамки, скопировать один и тот же документ дважды.
Более экономно включить оглавление в начало ”main.html”, в элемент noframes:
<html>
<body>
<noframes>
… оглавление …
</noframes>
… остальная часть документа …
</body>
</html>
Элемент noframes может использоваться в frameset-секции документа. Например:
<!doctype html public "-//w3c//dtd HTML 4.0 frameset//en"
"http://www.w3.org/tr/rec-html40">
<html>
<head>
<title>a frameset document with noframes</title>
</head>
<frameset cols="50%, 50%">
<frame src="main.html">
<frame src="table_of_contents.html">
<noframes>
<p>here is the <a href="main-noframes.html">
версия документа non-frame.</a>
</noframes>
</frameset>
</html>
24.5. Элемент iframe
| <!element iframe - - (%flow;)* | -- субокно в блоке текста --> |
<!attlist iframe
| %coreattrs; | -- id, class, style, title -- | |
| longdesc %uri; #implied | -- указатель на более длинное описание (дополнение к title) -- | |
| name cdata #implied | -- имя файла для адресации -- | |
| src %uri; #implied | -- источник содержимого рамки -- | |
| frameborder (1|0) 1 | -- request frame borders? -- | |
| marginwidth %pixels; #implied | -- ширина поля в пикселях -- | |
| marginheight %pixels; #implied | -- высота поля в пикселях -- | |
| scrolling (yes|no|auto) auto | -- наличие поля прокрутки -- | |
| align %ialign; #implied | -- вертикальное и горизонтальное выравнивание -- | |
| height %length; #implied | -- высота рамки -- | |
| width %length; #implied | -- ширина рамки -- > |
Описание атрибутов
longdesc = uri
Этот атрибут специфицирует связь с длинным описанием рамки. Это описание должно быть дополнением короткого описания, данного в атрибуте title.
name = cdata
Этот атрибут присваивает имя текущей рамке. Это имя может использоваться в последующих ссылках.
width = length
Ширина рамки.
height = length
Высота рамки.
Элемент Iframe позволяет разработчику ввести рамку в блок текста.
Эта процедура схожа с введением одного HTML-документа в другой с помощью элемента object. Информация, которая должна быть введена, определяется атрибутом src этого элемента. Содержимое элемента Iframe отображается только агентами пользователя, которые не поддерживают рамки. Пример, когда рамка вводится внутрь текста, приведен ниже.
<iframe src="foo.html" width="400" height="500"
scrolling="auto" frameborder="1">
[Ваш агент пользователя не поддерживает рамки или сконфигурирован без поддержки рамок]. Кликните для извлечения <a href="foo.html"> сопряженного документа. </a>]
</iframe>
Размеры этих рамок не могут быть изменены.
25. Формы
HTML-форма представляет собой часть документа, содержащая обычный текст, разметку (markup) и специальные элементы управления, называемые controls. controls служат для приема и обработки текста, вводимого пользователем. Форма – это аналог стандартного бланка, заполняемого пользователем. Заполненная форма может быть послана по почте другому пользователю, или передана программе для последующей обработки. Каждый control (графа бланка) должен иметь имя, а его значение определяется его типом. Ниже приведен пример формы, где используются метки и различного типа кнопки:
<form action="http://somesite.com/prog/adduser" method="post">
<p>
<label for="firstname">first name: </label>
<input type="text" id="firstname"><br>
<label for="lastname">last name: </label>
<input type="text" id="lastname"><br>
<label for="email">email: </label>
<input type="text" id="email"><br>
<input type="radio" name="sex" value="male"> male<br>
<input type="radio" name="sex" value="female"> female<br>
<input type="submit" value="send"> <input type="reset">
</p>
</form>
Каждый control имеет исходное и текущее значение, каждое из которых представляет собой символьную строку. Исходное значение может быть определено с помощью соответствующего атрибута.
Кнопки
Разработчики могут создавать три типа кнопок:
submit-кнопки. При активации эти кнопки преадресуют форму адресату. Форма может содержать более одной submit-кнопки.
Кнопки сброса: При активации эти кнопки возвращают все controls в исходное состояние.
Кнопки нажатия. Эти кнопки не имеют какого-либо фиксированного назначения. Каждой такой кнопке может быть поставлен в соответствие, например, скрипт клиента.
Разработчик создает кнопку с помощью элемента button или input. Следует иметь в виду, что элемент button предоставляет более широкие возможности, чем input.
Переключатели
Переключатели (chekbox; и радио-кнопки) представляют собой двухпозиционные приборы, которые могут находиться в состоянии on/off (вкл/выкл). Пользователь может переводить этот переключатель из одного состояния в другое. Переключатель находится в состоянии "on", когда установлен соответствующий атрибут управляющего элемента.
Несколько переключателей могут относиться к одному и тому же control, позволяя, например, выбрать одно из нескольких значений определенного параметра. Для формирования переключателя используется элемент input.
Радио-кнопки
Радио-кнопки схожи с переключателями. Но здесь при наличии нескольких кнопок, относящихся к одному имени control, перевод одной кнопки в состояние "on" переводит все другие кнопки с тем же именем в состояние "off". Для создания радио-кнопок используется элемент input.
Меню
Меню предоставляет пользователю выбор из нескольких возможностей. Для формирования меню используется элемент select, в сочетании с элементами optgroup и option.
Ввод текста
Разработчик может создать два типа controls, которые позволяют вводить текст.
Элемент input создает однострочный control для ввода, а textarea предназначен для многострочного ввода. В обоих случаях введенный текст становится текущим значением control.
Выбор файла
Этот тип control позволяет пользователю выбрать файлы, так что их содержимое будет введено в форму. Для обеспечения выбора файла используется элемент input.
Скрытые элементы управления control
Разработчик может создать control, которые не отображаются на экране, но величины которых заносятся в форму. Для формирования скрытого control используется элемент input.
Объектные control
Разработчик может ввести в форму общие объекты, так что соответствующие величины будут заноситься в форму. Для работы с объектными control используется элемент object.
Элементы, используемые для создания controls, обычно вводятся в элемент FORM, но могут появляться и вне декларации FORM, когда они используются для построения интерфейса пользователя.
25.1. Элемент FORM
| <!element form - - (%block;|script)+ -(form) | -- интерактивная форма --> | |
| <!attlist form %attrs; | -- %coreattrs, %i18n, %events -- | |
| action %uri; #required | -- хандлер форм со стороны сервера -- | |
| method (get|post) get | -- http метод для ввода форм -- | |
| enctype %contenttype; "application/x-www-form-urlencoded" | ||
| onsubmit %script; #implied | -- форма введена -- | |
| onreset %script; #implied | -- форма возвращена в исходное состояние -- | |
| accept-charset %charsets; #implied | -- список поддерживаемых символьных наборов --> |
Определение атрибутов
action = url
Этот атрибут специфицирует агента, который осуществляет обработку формы. Например, возможным значением атрибута может быть HTTP URI (для передачи формы программе) или mailto URI (для пересылки формы по электронной почте).
method = get|post
Этот атрибут специфицирует http-метод, который будет использоваться для представления данных. Возможные значения: "get" (по умолчанию) и "post". Метод post вводит пары имя/значение в тело формы.
enctype = content-type
Этот атрибут специфицирует тип содержимого (internet media type), используемого при передаче формы серверу (когда метод = "post"). Значение по умолчанию атрибута равно "application/x-www-form-urlencoded". Значение "multipart/form-data" должно использоваться в сочетании с type="file” элемента input.
accept-charset = charset list
Этот атрибут специфицирует список кодировок символов для входных данных, которые должны быть приняты сервером, обрабатывающим эти формы. Значения атрибута представляют собой список значений символьных комбинаций, разделенных пробелами или запятыми. Сервер должен интерпретировать этот список и воспринимать любой односимвольный код. Значение этого атрибута по умолчанию равно "unknown". Агент пользователя может интерпретировать это значение как символьную комбинацию, которая была использована для передачи документа, содержащего этот элемент form.
accept = content-type-list
Этот атрибут специфицирует список типов содержимого (в качестве разделителей используются занятые), которые сможет корректно воспринять и обработать сервер форм.
Элемент form работает как контейнер для controls. Он специфицирует:
Выкладку формы (заданную содержимым элемента).
Программу, которая будет обрабатывать заполненную форму (атрибут action). Принимающая программа должна быть способна разобрать пары имя/значение, для того чтобы использовать их.
Метод, посредством которого данные пользователя будут посланы серверу (атрибут method).
Кодировку символов, которая должна быть воспринята сервером, для того чтобы успешно произвести последующую обработку полученной формы (атрибут accept-charset). Агенты пользователя могут подсказать пользователю значения атрибута accept-charset и/или ограничить возможность ввода неузнаваемых символов.
Ниже приведен пример, который показывает форму, которая должна быть обработана программой "adduser". Форма посылается программе с помощью метода http "post”.
<form action="http://somesite.com/prog/adduser" method="post">
...form contents...
</form>
Следующий пример показывает, как послать форму по заданному электронному адресу:
<form action="mailto:kligor.t@gee.whiz.com" method="post">
...содержимое формы...
</form>
25.2. Элемент input
<!entity % inputtype
"(text | password | checkbox | radio | submit | reset |
file | hidden | image | button)" >
<!-- имя атрибута необходимо для всех кроме submit & reset -->
| <!element input - o empty | -- управление формой --> |
| <!attlist input %attrs; | -- %coreattrs, %i18n, %events -- |
| type %inputtype; text | -- what kind of widget is needed -- |
| name cdata #implied | -- представить как часть формы -- |
| value cdata #implied | -- необходимо для радио-кнопок и переключателей -- |
| checked (checked) #implied | -- для радио-кнопок и переключателей -- |
| disabled (disabled) #implied | -- не доступно в данном контексте -- |
| readonly (readonly) #implied | -- для текста и пароля -- |
| size cdata #implied | -- разный для каждого типа полей -- |
| maxlength number #implied | -- макс. число символов для текст. полей -- |
| src %uri; #implied | -- для полей с изображением -- |
| alt cdata #implied | -- краткое описание -- |
| usemap %uri; #implied | -- использование карты изображения клиента -- |
| tabindex number #implied | -- position in tabbing order -- |
| accesskey %character; #implied | -- клавиша доступа -- |
| onfocus %script; #implied | -- элемент выделен -- |
| onblur %script; #implied | -- элемент не выделен -- |
| onselect %script; #implied | -- некоторый текст был выбран -- |
| onchange %script; #implied | -- значение элемента изменилось -- |
| accept %contenttypes; #implied | -- list of mime types for file upload --> |
Определение атрибутов
type = text|password|checkbox|radio|submit|reset|file|hidden|image|button
Этот атрибут специфицирует тип создаваемого control. Значение по умолчанию "text".
name = cdata
Этот атрибут присваивает имя control.
value = cdata
Этот атрибут специфицирует начальное значение control.
size = cdata
Этот атрибут сообщает агенту пользователя исходную ширину control. Ширина задается в пикселях, за исключением случая, когда тип атрибута "text" или "password". В этом варианте ширина измеряется числом символов.
maxlength = number
Когда тип атрибута "text" или "password", этот атрибут специфицирует максимальное число символов, которое предлагается ввести пользователю. Это число может превзойти указанный размер, тогда агент пользователя должен предложить механизм скроллинга.
checked.
Когда тип атрибута "radio" или "checkbox", этот булев атрибут указывает, что кнопка нажата. Агент пользователя должен игнорировать этот атрибут для всех других видов control.
src = url
Когда тип атрибута "image", этот атрибут специфицирует положение изображения, которое будет использовано для украшения кнопки.
Атрибут type элемента input определяет то, какой управляющий элемент создан.
| text | Этот тип создает текстовый бокс на одну строчку. Значение текстового control равно введенному тексту. |
| password | Подобен типу “text”, но отображение ввода делается так, что вводимые символы не видны (напр. каждому введенному символу ставится в соответствие *). Значение данного типа control равно введенному тексту. Служит для ввода паролей. |
| checkbox | Представляет собой двух позиционный переключатель (вкл/выкл=on/off). Когда переключатель в положении on, значение checkbox = “active”. Состояние переключателя передается только в случае, когда переключатель в состоянии on. |
Нижеследующий фрагмент HTML представляет собой пример простой формы, которая позволяет пользователю ввести свою фамилию имя, электронный адрес и т.д.
<form action="http://somesite.com/prog/adduser" method="post">
<p>
first name: <input type="text" name="firstname"><br>
last name: <input type="text" name="lastname"><br>
email: <input type="text" name="email"><br>
<input type="radio" name="sex" value="male"> male<br>
<input type="radio" name="sex" value="female"> female<br>
<input type="submit" value="send"> <input type="reset">
</p>
</form>
| radio | также является двухпозиционным переключателем. Единственным отличием от checkbox является то, что при наличии нескольких радио-кнопок с идентичным именем в состоянии on может быть всегда только одна. | |
| submit | формирует кнопку submit. При активации этой кнопки пользователем, форма передается по адресу, указанному атрибутом action элемента form. Форма может содержать несколько таких кнопок. | |
| image | Создает графический образ кнопки submit. Значение атрибута src специфицирует URL изображения кнопки. Рекомендуется воспользоваться атрибутом alt, чтобы создать альтернативный текст для агентов пользователя, не поддерживающих графику. Если кнопка активизирована, форма передается серверу-адресату. Передаваемые данные содержат значения name.x=x и name.y=y, где “name” – значение атрибута name, х – число пикселей от левого края изображения, а у – число пикселей от верхней кромки изображения. Это позволяет варьировать реакцию сервера от координат места, где была нажата кнопка мышки. | |
| reset | Создает кнопку сброса. При нажатии этой кнопки пользователем всем controls формы присваиваются исходные значения, заданные атрибутом value. Пара имя/значение кнопки reset вместе с формой не пересылается. | |
| button | Создает кнопку, которая не имеет заранее определенной функции. Эта функция определяется скриптом клиента, который запускается при нажатии этой кнопки. Например, создадим кнопку, которая вызывает функцию verify: | |
| <input type=”button” value=”click me” onclick=”verify()”> | ||
| hidden | Создает элемент, не видимый при работе агента пользователя. Однако, имя и значение элемента передаются серверу вместе с формой. Эта форма controls используется для запоминания информации в паузах между обменами клиент/сервер. Следующий control типа hidden, тем не менее, должен передавать свое значение вместе с формой. | |
| <input type=”password” style=”display:none” | ||
| name=”invisible-password” | ||
| value=”mypassword”> | ||
| file | Позволяет пользователю присоединить содержимое файла к форме. |
Следующий пример представляет собой анкету, предложенную выше, дополненную кнопками submit и reset. Кнопки содержат изображения, для чего использован элемент img.
<form action="http://somesite.com/prog/adduser" method="post">
<p>
first name: <input type="text" name="firstname"><br>
last name: <input type="text" name="lastname"><br>
email: <input type="text" name="email"><br>
<input type="radio" name="sex" value="male"> male<br>
<input type="radio" name="sex" value="female"> female<br>
<button name="submit" value="submit" type="submit">
send<img src="/icons/wow.gif" alt="wow"></button>
<button name="reset" type="reset">
reset<img src="/icons/oops.gif" alt="oops"></button>
</p>
</form>
Внешне данная форма будет выглядеть для пользователя следующим образом:
25.3. Элемент isindex
<!element isindex - o empty>
<!attlist isindex
| %coreattrs; | -- id, class, style, title -- | |
| %i18n; | -- lang, dir -- | |
| prompt cdata @implied | -- сообщение-приглашение (prompt) --> |
Элемент использовать не рекомендуется, вместо него лучше применять элемент input.
Описание атрибута
prompt = cdata
Атрибут специфицирует строку приглашения для ввода. Служит для ввода одной строки пользователем. Например:
<isindex prompt=”enter your name: “>
Та же задача решается с использованием элемента input следующим образом (рекомендуемый вариант):
<form action=”…” method=”post”>
enter your name: <input type=”text”>
</form>
25.4. Элемент button
<!element button - - (%flow;)* -(a|%formctrl;|form|fieldset) -- клавиша -->
<!attlist button
| %attrs | -- %coreattrs, %i18n, %events -- | |
| name cdata #implied | ||
| value cdata #implied | -- при представлении посылать серверу -- | |
| type (button|submit|reset) submit | -- для использования в качестве кнопки -- | |
| disabled (disabled) #implied | -- в данном контексте недоступно -- | |
| tabindex number #implied | -- position in tabbing order -- | |
| accesskey %character; #implied | -- клавиша доступа -- | |
| onfocus %script; #implied | -- элемент выделен -- | |
| onblur %script; #implied | -- элемент не выделен -- > |
Описание атрибутов
name = cdata
Этот атрибут присваивает имя кнопке.
value = cdata
Этот атрибут присваивает значение кнопке.
type = button | submit | reset
Этот атрибут декларирует тип кнопки. Когда атрибут не задан, поведение кнопки не определено. Возможные значения:
| button: | Создает простую кнопку, которая может запускать скрипт. | |
| submit: | Создает кнопку, которая служит для отправки формы серверу (значение по умолчанию). | |
| reset: | Создает кнопку сброса для формы. |
Элемент button с типом “submit”, содержащий изображение (т.е. элемент img), очень похож на элемент input с типом “image”. Но их поведение на фазе отображения различно. В этом контексте элемент input предполагает плоское изображение, а button – объемное (кнопка нажимается и отбрасывает тень). Ниже приведен пример использования элементов input и button:
<form action="http://somesite.com/prog/adduser" method="post"><p>
first name: <input type="text" name="firstname"><br>
last name: <input type="text" name="lastname"><br>
email: <input type="text" name="email"><br>
<input type="radio" name="sex" value="male"> male<br>
<input type="radio" name="sex" value="female"> female<br>
<button name="submit" value="submit" type="submit">
send<img src="/icons/wow.gif" alt="wow"></button>
<button name="reset" type="reset">
reset<img src="/icons/oops.gif" alt="oops"></button>
</p>
</form>
Если используется button с элементом img, рекомендуется применение img-элемента с атрибутом alt, чтобы обеспечить совместимость с агентами пользователя, не поддерживающими графику. Недопустимо использование карты изображения с img в элементе button:
<button>
<img src=”foo.gif” usemap=”…”>
</button>
Элемент button с типом “reset” очень похож на элемент input с типом “reset”.
25.5. Элемент select
<!element select - - (optgroup|option)+ -- селектор опции -->
<!attlist select
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| name cdata #implied | -- имя поля -- | |
| size number #implied | -- rows visible -- | |
| multiple (multiple) #implied | -- по умолчанию один выбор -- | |
| disabled (disabled) #implied | -- недоступно в данном контексте -- | |
| tabindex number #implied | -- position in tabbing order -- | |
| onfocus %script; #implied | -- элемент выделен -- | |
| onblur %script; #implied | -- элемент не выделен -- | |
| onchange %script; #implied | -- значение элемента изменено --> |
Определение атрибутов
name = cdataЭтот атрибут присваивает имя control.
size = number
Если элемент select представлен в виде окна с полосой прокрутки, этот атрибут специфицирует число рядов в списке, которые должны быть видны одновременно. Визуальный агент пользователя не должен представлять элемент select в качестве окна; он может использовать и другой механизм, например, выпадающее меню.
multiple
Этот булев атрибут позволяет обеспечить множественный выбор. При отсутствии этого атрибута допускается только один выбор.
Элемент select создает список вариантов, из которых может выбирать пользователь. Каждый элемент select должен предложить как минимум один вариант. Каждый вариант специфицируется с помощью элемента option.
| <!element option - o (#pcdata) | -- доступный выбор --> | |
| <!attlist option | -- %coreattrs, %i18n, %events -- | |
| %attrs; | ||
| selected (selected) #implied | ||
| disabled (disabled) #implied | -- недоступно в данном контексте -- | |
| label %text; #implied | -- для использования иерархического меню -- | |
| value cdata #implied | -- содержимое элемента по умолчанию --> |
Описание атрибутов элемента option selected
Этот булев атрибут определяет то, что данная опция является уже выбранной (pre-selected).
value = cdata
Этот атрибут специфицирует исходное значение control. Если атрибут не установлен, исходное значение определяется содержимым элемента option.
label = text
Этот атрибут позволяет разработчику специфицировать более короткую метку, чем содержимое элемента option. Если атрибут задан, агент пользователя должен использовать в качестве метки опции значение атрибута, а не содержимое элемента option.
Элемент select помогает создать меню, с помощью которого осуществляется выбор опции. Ниже приведен пример создания такого меню.
<form action="http://somesite.com/prog/component-select" method="post">
<p>
<select multiple size="4" name="component-select">
<option selected value="component_1_a">component_1</option>
<option selected value="component_1_b">component_2</option>
<option>component_3</option>
<option>component_4</option>
<option>component_5</option>
<option>component_6</option>
<option>component_7</option>
</select>
<input type="submit" value="send"><input type="reset">
</p>
</form>
Атрибут size определяет, что в окне должно быть видно 4 опции. Реальное число опций равно 7, по этой причине выбор остальных опций возможен с помощью механизма скролинга.
Элемент optgroup позволяет разработчику логически сгруппировать опции. Это особенно удобно, когда пользователь должен сделать выбор из длинного списка опций. В HTML 4.0 все элементы optgroup должны быть специфицированы в пределах элемента select (т.е., группы не могут вкладываться друг в друга). В ниже приведенном примере показано использование элемента optgroup:
<form action="http://somesite.com/prog/someprog" method="post">
<p>
<select name="comos">
<optgroup label="portmaster 3">
<option label="3.7.1" value="pm3_3.7.1">portmaster 3 with comos 3.7.1
<option label="3.7" value="pm3_3.7">portmaster 3 with comos 3.7
<option label="3.5" value="pm3_3.5">portmaster 3 with comos 3.5
</optgroup>
<option label="3.7" value="pm2_3.7">portmaster 2 with comos 3.7
<option label="3.5" value="pm2_3.5">portmaster 2 with comos 3.5
</optgroup>
<optgroup label="irx">
<option label="3.7r" value="irx_3.7r">irx with comos 3.7r
<option label="3.5r" value="irx_3.5r">irx with comos 3.5r
</optgroup>
</select>
</form>
25.6. Элемент optgroup
| <!element optgroup - - (option)+ | -- группа опции --> | |
| <!attlist optgroup | ||
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| disabled (disabled) #implied | -- недоступно в данном контексте -- |
Определение атрибута
label = text [cs]
Этот атрибут специфицирует метку опции для группы опций.
Когда форма передается на обработку, каждый из выборов группируется с именем “component-select”.
25.7. Элемент textarea
| <!element textarea - - (#pcdata) | -- поле многострочного текста --> |
<!attlist textarea
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| name cdata #implied | ||
| rows number #required | ||
| cols number #required | ||
| disabled (disabled) #implied | -- недоступно в данном контексте -- | |
| readonly (readonly) #implied | ||
| tabindex number #implied | -- position in tabbing order -- | |
| accesskey %character; #implied | -- клавиша доступа -- | |
| onfocus %script; #implied | -- элемент выделен -- | |
| onblur %script; #implied | -- элемент не выделен -- | |
| onselect %script; #implied | -- некоторый текст выбран -- | |
| onchange %script; #implied | -- значение элемента изменено -- > |
Определение атрибутов
name = cdata [ci]
Этот атрибут присваивает имя control.
rows = number [cn]
Этот атрибут специфицирует номер видимой строки текста. Пользователь может ввести больше строк, чем это число, по этой причине агент пользователя должен предоставить средства для скролирования текста, чтобы обеспечить доступ к строкам за пределами видимости окна.
cols = number [cn]
Этот атрибут специфицирует видимую ширину строки (в символах). Пользователь может иметь возможность ввести более длинные строки, так что агент пользователя должен обеспечить средства для скролирования текста по горизонтали. Агент пользователя может разрывать строки, чтобы их сделать видимыми по всей длине без горизонтального скролинга.
Пример использования элемента textarea для создания текстовой области размером 20 строк по 80 колонок. В исходный момент зона содержит только две строки.
<form action="http://somesite.com/prog/text-read" method="post">
<p>
<textarea name="thetext" rows="20" cols="80">
first line of initial text.
second line of initial text.
</textarea>
<input type="submit" value="send"><input type="reset">
</p>
</form>
25.8. Элемент label
<!element label - - (%inline;)* -(label) -- form field label text -->
<!attlist label
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| for idref #implied | -- matches field id value -- | |
| accesskey %character; #implied | -- клавиша доступа -- | |
| onfocus %script; #implied | -- элемент выделен -- | |
| onblur %script; #implied | -- элемент не выделен --> |
Определение атрибута
for = idref [cs]
Этот атрибут устанавливает соответствие между меткой и control. При наличии этого атрибута его значение должно совпадать с атрибутом id другого control того же документа. При отсутствии этого атрибута метка ставится в соответствие содержимому элемента.
Элемент label может использоваться для привязки информации к другим элементам control (за исключением других элементов label). Ниже приведены два примера использования элемента label.
<form action="..." method="post">
<table>
<tr>
<td><label for="fname">first name</label>
<td><input type="text" name="firstname" id="fname">
<tr>
<td><label for="lname">last name</label>
<td><input type="text" name="lastname" id="lname">
</table>
</form>
<form action="http://somesite.com/prog/adduser" method="post">
<p>
<label for="firstname">first name: </label>
<input type="text" id="firstname"><br>
<label for="lastname">last name: </label>
<input type="text" id="lastname"><br>
<label for="email">email: </label>
<input type="text" id="email"><br>
<input type="radio" name="sex" value="male"> male<br>
<input type="radio" name="sex" value="female"> female<br>
<input type="submit" value="send"> <input type="reset">
</p>
</form>
Для установления неявной связи между меткой и другим control контрольный элемент должен находиться внутри содержимого элемента label. В этом случае label может содержать только один контрольный элемент. В примере две метки неявно поставлены в соответствие двум вводимым текстам:
<form action="..." method="post">
<p>
<label>
first name
<input type="text" name="firstname">
</label>
<label>
<input type="text" name="lastname">
last name
</label>
</p>
</form>
25.9. Элементы fieldset и legend
<!-- #pcdata служит для решения проблемы смешанных данных, согласно спецификации здесь допустимы только whitespace! -->
<!element fieldset - - (#pcdata,legend,(%flow;)*) >
<!attlist fieldset
| %attrs; | -- %coreattrs, %i18n, %events -- > |
| <!element legend - - (%inline;)* | -- легенда поля --> |
<!entity % lalign "(top|bottom|left|right)">
<!attlist legend
| %attrs; | -- %coreattrs, %i18n, %events -- > |
| accesskey %character; #implied | -- клавиша доступа -- > |
Определение атрибута элемента legend
align = top|bottom|left|right
Не рекомендуется к применению. Этот атрибут специфицирует положение легенды по отношению к набору полей. Возможные значения:
| top: | Легенда размещается сверху (значение по умолчанию). |
| bottom: | Легенда размещается внизу. |
| left: | Легенда размещается слева. |
| right: | Легенда размещается справа. |
Элемент fieldset позволяет разработчику тематически группировать управляющие элементы. Группирование облегчает пользователю понимание их функций и в то же время упрощает графическому агенту пользователя их размещение.
Элемент legend позволяет разработчику поставить в соответствие надпись, поясняющую назначение полей, и fieldset. Ниже представлен пример использования этих элементов.
<form action="..." method="post">
<p>
<fieldset>
<legend>personal information</legend>
last name: <input name="personal_lastname" type="text" tabindex="1">
first name: <input name="personal_firstname" type="text" tabindex="2">
address: <input name="personal_address" type="text" tabindex="3">
...more personal information...
</fieldset>
<fieldset>
<legend>medical history</legend>
<input name="history_illness"
type="checkbox"
value="smallpox" tabindex="20"> smallpox
<input name="history_illness"
type="checkbox"
value="mumps" tabindex="21"> mumps
<input name="history_illness"
type="checkbox"
value="dizziness" tabindex="22"> dizziness
<input name="history_illness"
type="checkbox"
value="sneezing" tabindex="23"> sneezing
...more medical history...
</fieldset>
<fieldset>
<legend>current medication</legend>
are you currently taking any medication?
<input name="medication_now"
type="radio"
value="yes" tabindex="35">yes
<input name="medication_now"
type="radio"
value="no" tabindex="35">no
if you are currently taking medication, please indicate
it in the space below:
<textarea name="current_medication"
rows="20" cols="50"
tabindex="40">
</textarea>
</fieldset>
</form>
Обратите внимание на то, что в этом примере можно улучшить представление формы путем выравнивания элементов в пределах каждого fieldset (с помощью стилевых листов), добавив цвета, подобрав шрифты и используя скрипты.
26. Выделение элементов
Активный элемент HTML-документа должен быть выделен. Существует несколько способов выделения элемента:
Пометить элемент с помощью мышки.
Выделить нужный элемент, перемещаясь от элемента к элементу с помощью стрелок или других клавиш.
Выбрать нужный элемент, нажав определенную комбинацию клавиш.
Описание атрибута
tabindex = integer
Этот атрибут специфицирует положение текущего элемента по порядку, значение может быть положительным или отрицательным.
Элементы, которые могут быть выделены, должны обрабатываться агентом пользователя согласно следующим правилам:
Тем элементам, которые поддерживают атрибут tabindex, присваиваются положительные значения и они просматриваются первыми. Процесс просмотра начинается с меньших значений tabindex и продолжается в направлении больших. Элементы, которые имеют равные значения tabindex должны обрабатываться в порядке их появления в документе.
Элементы, для которых атрибут tabindex не определен или не поддерживается, просматриваются в порядке их появления в документе.
Те элементы, которым приписано отрицательное значение tabindex, не участвуют в процессе просмотра.
Атрибут tabindex поддерживается элементами a, area, object, input, select, textarea и button. Ниже предлагается пример.
<!doctype html public "-//w3c//dtd html 4.0//en"
"http://www.w3.org/tr/rec-html40/strict.dtd">
<html>
<head>
<title>a document with form</title>
</head>
<body>
...some text...
<p>go to the
<a tabindex="10" href="http://www.w3.org/">w3c web site.</a>
...some more...
<button type="button" name="get-database"
tabindex="1" onclick="get-database">
get the current database.
</button>
...some more...
<form action="..." method="post">
<p>
<input tabindex="1" type="text" name="field1">
<input tabindex="2" type="text" name="field2">
<input tabindex="3" type="submit" name="submit">
</p>
</form>
</body>
</html>
Ключи доступа
accesskey = cdata
Этот атрибут присваивает ключ доступа элементу. Ключ доступа представляет собой одиночный символ в текущей кодировке агента пользователя.
Нажатие клавиши, соответствующей ключу доступа, приводит к выбору элемента.Действия, которые будут выполнены при выборе, зависят от элемента. Атрибут accesskey поддерживается элементами: label и legend. В приведенном примере клавиша “u” ставится в соответствие элементу управления input.
<form action="..." method="post">
<p>
<label for="fuser" accesskey="u">
user name
</label>
<input type="text" name="user" id="fuser">
</p>
</form>
В ниже приведенном примере ключ доступа поставлен в соответствие связи, описанной элементом А. Нажатие клавиши доступа (c) приводит к вызову другого элемента.
<p><a accesskey="c"
rel="contents"
href="http://someplace.com/specification/contents.html">
table of contents</a>
В системе MS Windows для активации ключа доступа одновременно с ним следует нажать клавишу alt.
Атрибут disabled
Когда этот булев атрибут установлен для control формы, он блокирует данный вид контроля для ввода пользователя. Атрибут disabled поддерживается элементами input, textarea, select, option, object, label и button.
Блокированный элемент не может быть выделен, он игнорируется при обходе элементов и значения блокированного элемента не передается вместе с формой. В ниже предлагаемом примере блокированный элемент input не может воспринять ввод пользователя и передать его с формой.
<input disabled name="fred" value="stone">
Изменить значение атрибута динамически можно только с помощью скрипта.
Атрибут readonly
Этот булев атрибут при установке запрещает изменение control. Элементы, предназначенные только для чтения, могут быть выбраны, но не могут быть изменены пользователем. Значения control в этом случае передается вместе с формой. Атрибут readonly поддерживается элементами input, text, password и textarea.
27. Скрипты
На стороне клиента скрипт представляет собой программу, которая может сопровождать документ HTML или быть непосредственно встроена в него. Программа исполняется на ЭВМ клиента при загрузке документа или при активации определенной связи. Скрипт предлагает разработчику заметно расширить возможности HTML-документа. В частности:
Скрипт может динамически изменять содержимое документа.
Скрипт может использоваться для обработки вводимой пользователем информации.
Скрипт может быть запущен каким-либо событием (выделение фрагмента, операции с мышкой, выгрузка документа и т.д.).
Скрипт может быть поставлен в соответствие одному из control формы и управляться им.
Существует два типа скриптов, которые могут быть подключены к документу:
Исполняемые только раз при загрузке документа агентом пользователя (это прежде всего скрипты элемента script).
Исполняемые каждый раз, когда происходит какое-то определенное событие. Такие скрипты могут быть подключены ко многим документам.
27.1. Элемент script
| <!element script - - %script; | -- текст скрипта --> |
<!attlist script
| charset %charset; #implied | -- кодировка символов, подключенного ресурса -- |
| type %contenttype; #required | -- тип содержимого языка скрипта -- |
| src %uri; #implied | -- uri для внешнего скрипта -- |
| defer (defer) #implied | -- ua может отложить исполнение скрипта --> |
Определение атрибутов
src = URI [ct]
Этот атрибут специфицирует местонахождения внешнего скрипта.
type = content-type
Этот атрибут специфицирует язык скрипта, включенного в элемент. Язык специфицируется в содержимом content-type (напр., "text/javascript"). Разработчик должен выдать значения этого атрибута, так как не существует никакого значения по умолчанию.
language = cdata
Не рекомендуется к применению. Этот атрибут специфицирует язык скрипта, включенного в элемент. Его содержимое представляет собой идентификатор языка. Но из-за отсутствия стандарта атрибут type предпочтительнее.
defer
Установка этого булева атрибута сообщает агенту пользователя о том, что скрипт не будет генерировать какого-либо текста документа, что позволяет агенту пользователя продолжить разборку и представление документа.
Элемент script размещает скрипт внутри документа. Этот элемент может встретиться в head или body HTML-документа любое число раз. Сам скрипт может находиться в содержательной части элемента script или во внешнем файле. Если атрибут src не установлен, агент пользователя должен интерпретировать содержимое элемента, как скрипт. Если же src содержит URL, то агент пользователя должен игнорировать содержимое элемента и получить скрипт через URL. Разработчик должен идентифицировать язык скрипта. Для того чтобы определить язык всех скриптов в документе, необходимо включить следующую meta-декларацию в head документа:
<meta http-equiv="content-script-type" content="type">
где “type” соответствует internet media type, именующему язык скрипта. В отсутствии META-декларации, значение по умолчанию может быть установлено с помощью HTTP-заголовка “content-script-type”
content-script-type: type
где “type” соответствует internet media type.
27.2. Локальная декларация языка скрипта
Можно описать язык скрипта в каждом элементе script независимо с помощью атрибута type. В отсутствии значения языка по умолчанию этот атрибут должен быть обязательно установлен. При наличии значения по умолчанию атрибут type переписывает это значение. Ниже приведен пример, где значение языка скриптов по умолчанию равно “text/tcl”. Один скрипт включен в заголовок, он размещен во внешнем файле и написан на языке “text/vbscript”. Включен скрипт и в тело script (написан на “text/javascript”).
<!doctype html public "-//w3c//dtd html 4.0//en"
"http://www.w3.org/tr/rec-html40/strict.dtd">z
<html>
<head>
<title>a document with script</title>
<meta http-equiv="content-script-type" content="text/tcl">
<script type="text/vbscript" src="http://someplace.com/progs/vbcalc">
</script>
</head>
<body>
<script type="text/javascript">
...some javascript...
</script>
</body>
</html>
27.3. Ссылки на html-документы из скрипта
В каждом языке имеется соглашение относительно взаимодействия с HTML-объектами. Содержимым элемента script является скрипт и по этой причине агент пользователя не должен рассматривать его как часть HTML-текста. Текст скрипта начинается сразу после начальной метки и завершается любой меткой, которая начинается с символов “</”. Ниже следующий пример не является корректным из-за наличия “</em>” символов внутри элемента script (эта комбинация указывает на окончание скрипта):
<scipt type=”text/javascript”>
| document.write (“<em> this won’t work</em>” |
</script>
Корректная версия записи выглядит как:
<scipt type=”text/javascript”>
| document.write (“<em> this will work<\/em>” |
</script>
В tcl можно это записать как:
<scipt type=”text/tcl”>
| document.write (“<em> this will work<\/em>” |
</script>
Определения атрибутов
onload = script [ct]
Событие onload происходит, когда пользователь заканчивает загрузку окна в рамках frameset. Этот атрибут может использоваться с элементами body и frameset.
onunload = script [ct]
Событие onunload происходит, когда агент пользователя удаляет документ из окна или рамки. Этот атрибут может использоваться с элементами BODY и frameset.
onclick = script [ct]
Событие onclick происходит, когда на устройстве (например, мышке), указывающем на клавишу, нажата кнопка. Этот атрибут может использоваться с большинством элементов.
ondblclick = script
Событие ondblclick происходит, когда на устройстве, указывающем на клавишу, кнопка нажата дважды. Этот атрибут может использоваться с большинством элементов.
onmousedown = script
Событие onmousedown происходит, когда на устройстве, указывающем на клавишу, кнопка находится в нажатом состоянии. Этот атрибут может использоваться с большинством элементов.
onmouseup = script
Событие onmouseup происходит, когда на устройстве, указывающем на клавишу, кнопка отпущена. Этот атрибут может использоваться с большинством элементов.
onmouseover = script
Событие onmouseover происходит, когда указатель устройства, наезжает на клавишу (элемент). Этот атрибут может использоваться с большинством элементов.
onmousemove = script
Событие onmousemove происходит, когда устройство указывающее на элемент, перемещено. Этот атрибут может использоваться с большинством элементов.
onmouseout = script
Событие onmouseout происходит, когда позиционер указателя сдвигается с поля элемента. Этот атрибут может использоваться с большинством элементов.
onfocus = script
Событие onfocus происходит, когда элемент оказывается выделен с помощью прибора-указателя или каким-либо другим способом (например, с помощью клавиш).
Этот атрибут может использоваться с: label, input, select, textarea, и button.
onblur = script
Событие onblur происходит, когда элемент перестает быть выделенным с помощью прибора-указателя или каким-либо другим способом. navigation. Этот атрибут может использоваться с теми же элементами, что и onfocus.
onkeypress = script
Событие onkeypress происходит, когда клавиша нажата и отпущена на элементе. Этот атрибут может использоваться с большинством элементов.
onkeydown = script
Событие onkeydown происходит, когда клавиша нажата на элементе. Этот атрибут может использоваться с большинством элементов.
onkeyup = script
Событие onkeyup происходит, когда клавиша отпущена на элементе. Этот атрибут может использоваться с большинством элементов.
onsubmit = script
Событие onsubmit происходит, когда форма передана. Этот атрибут используется с элементом form.
onreset = script
Событие onreset происходит, когда форма сброшена. Этот атрибут используется с элементом form.
onselect = script
Событие onselect происходит, когда пользователь выбирает некоторый текст втекстовом поле. Этот атрибут может использоваться с элементами input и textarea.
onchange = script
Событие onchange происходит, когда control перестает быть выбранным и его значение модифицировано с момента выбора. Этот атрибут может использоваться с элементами input, select и textarea.
Имеется возможность установить соответствие между определенными действиями и несколькими событиями, когда пользователь взаимодействует с агентом пользователя. Управляющие элементы, такие как input, select, button, textarea и label реагируют на те или иные события. В следующем примере необходимо ввести имя пользователя в текстовое поле. Когда пользователь пытается покинуть это поле, событие onblur вызывает функцию javascript, которая проверяет корректность введенного имени.
<input name="num"
onchange="if (!checknum(this.value, 1, 10))
{this.focus();this.select();} else {thanks()}"
value="0">
Вот пример скрипта vbscript для обработки событий в текстовом поле:
<input name="edit1" size="50">
<script type="text/vbscript">
sub edit1_changed()
if edit1.value = "abc" then
button1.enabled = true
else
button1.enabled = false
end if
end sub
</script>
Ниже прведен пример с использованием tcl:
<input name="edit1" size="50">
<script type="text/tcl">
proc edit1_changed {} {
if {[edit value] == abc} {
button1 enable 1
} else {
button1 enable 0
}
}
edit1 onchange edit1_changed
</script>
Здесь приведен пример Javascript для демонстрации установки связи между скриптом и событием (в случае нажатия клавиши на мышке):
<button type="button" name="mybutton" value="10">
<script type="text/javascript">
function my_onclick() {
. . .
}
document.form.mybutton.onclick = my_onclick
</script>
</button>
Ниже представлен более интересный хандлер окна:
<script type="text/javascript">
function my_onload() {
. . .
}
var win = window.open("some/other/uri")
if (win) win.onload = my_onload
</script>
На tcl это выглядит как:
<script type="text/tcl">
proc my_onload {} {
. . .
}
set win [window open "some/other/uri"]
if {$win != ""} {
$win onload my_onload
}
</script>
Атрибуты скриптов для событий определяются как cdata. Значение атрибута должно быть заключено в одинарные или двойные кавычки. С учетом ограничений, налагаемых программой лексической разборки, случаи появления (“) и “&” в атрибуте хандлера событий должны быть записаны следующим образом:
'"' должно быть записано как """ или """
'&' должно быть записано как "&" или "&"
Поэтому ниже представленный пример должен быть записан как:
<input name="num" value="0"
onchange="if (compare(this.value, "help")) {gethelp()}">
sgml разрешает введение (‘) в строку атрибута следующим образом:
“this is ‘fine’ ” and “so is “this” ’
28. Динамическая модификация документов
Скрипты, которые исполняются в процессе загрузки документа, могут динамически модифицировать его содержимое. Эта возможность зависит от языка, используемого для написания скрипта. Динамическая модификация документов осуществляется следующим образом:
Сначала определяются все элементы script для того, чтобы загрузить документ.
Определяются все конструкции скрипта в пределах данного элемента script, которые генерируют SGML cdata. Полученный в результате текст загружается в документ в месте размещения элемента script.
Сгененированная cdata подвергается обратному преобразованию.
Следующий пример иллюстрирует то, как скрипты могут динамически модифицировать текст.
<title>test document</title>
<script type="text/javascript">
document.write("<p><b>hello world!<\/b>")
</script>
Приведенный выше текст дает тот же результат, что и html-текст:
<title>test document</title>
<p><b>hello world!</b>
28.1. Элемент noscript
<!element noscript - - (%block;)+
-- альтернативный текст для случая безскриптового отображения -->
<!attlist noscript
| %attrs; | -- %coreattrs, %i18n, %events -- > |
Элемент noscript позволяет разработчику варьировать содержимое, даже когда скрипт не исполняется. Содержимое элемента noscript должно отображаться соответствующим агентом пользователя в следующих случаях:
Агент пользователя сконфигурирован так, что он не поддерживает скрипты.
Агент пользователя не поддерживает язык скрипта, использованный в элементе script.
Агент пользователя, не поддерживающий скрипты для стороны клиента, должен осуществлять разборку и представление содержимого элемента. В следующем примере агент пользователя, который исполняет script, включит некоторую динамически созданную информацию, в текст документа.
Если агент пользователя не поддерживает скрипты, пользователь может, тем не менее, получить эту информацию через сеть.
<script type="text/tcl">
...некоторый tcl-скрипт для введения данных...
</script>
<noscript>
<p>access the <a href="http://someplace.com/data">data.</a>
</noscript>
Агент пользователя, который не распознает элемент script, вероятно будет разбирать и отображать содержимое элемента, как текст. Некоторые интерпретаторы скриптов, включая те, которые ориентированы на Javascript, VBscript и TCL, позволяют помещать фрагменты текстов скриптов в SGML-комментарии. Тогда агент пользователя, не узнавший элемент script, игнорирует его текст, считая его комментарием, а продвинутый интерпретатор скриптов распознает скрипт, помещенный в комментарий, и исполнит его. Другим решением проблемы является помещение скрипта во внешний документ.
28.2. Комментирование скриптов в javascript
Интерпретатор javascript позволяет вводить строку “<!--“ в начало элемента script и игнорировать все символы, следующие за ней вплоть до конца строки. javascript интерпретирует “//” как начало комментария, который следует до конца текущей строки. Это необходимо, для того чтобы скрыть строку “-->” от интерпретатора javascript.
<script type="text/javascript">
<!-- to hide script contents from old browsers
function square(i) {
document.write("the call passed ", i ," to the function.","<br>")
return i * i
}
document.write("the function returned ",square(5),".")
// end hiding contents from old browsers -->
</script>
28.3. Комментирование скриптов в vbscript
В vbscript символ одиночной кавычки воспринимается, как начало комментария, который продолжается до конца строки. Это может быть использовано для того, чтобы спрятать “-->” от vbscript. Например:
<script type="text/vbscript">
<!--
sub foo()
...
end sub
‘ -->
</script>
28.4. Комментирование скриптов в tcl
В TCL для начала строки комментария используется символ “#” (действует до конца строки).
<script type="text/tcl">
<!-- чтобы скрыть содержимое скрипта от старых броузеров
proc square {i} {
document write "the call passed $i to the function.<br>"
return [expr $i * $i]
}
document write "the function returned [square 5]."
# end hiding contents from old browsers -->
</script>
Некоторые броузеры считают комментарий завершившимся на первом символе “>”.
29. Верификация документов
Многие разработчики при проверке своих документов полагаются на ограниченное число броузеров, предполагая, что если эти броузеры могут работать с их документами корректно, то они лишены ошибок. К сожалению, это очень неэффективный способ верификации документов, прежде всего из-за того, что многие броузеры приспособлены работать с не вполне корректными документами.
Для более тщательной проверки рекомендуется воспользоваться интерпретатором SGML, например, в случае проверки соответствия документа требованиям HTML 4.0 DTD это может быть NSGMLS. Если декларации типа в вашем документе включают URI, и ваш интерпретатор SGML поддерживает этот тип системных идентификаторов, то он получит DTD (Document Type Definition) непосредственно. В противном случае можно воспользоваться каталогом образцов SGML.
Предполагается, что DTD спасено в виде файла "strict.dtd", а объекты (entities) записаны в файлы "htmllat1.ent", "htmlsymbol.ent" и "htmlspecial.ent". В любом случае следует проверить то, что ваш интерпретатор SGML может работать с уникодами.
Следует иметь в виду, что такая проверка, хотя и полезна и настойчиво рекомендуется, не может гарантировать полного соответствия документа требованиям спецификации HTML 4.0. Это происходит потому, что интерпретатор SGML базируется на определенных SGML DTD, не выражают всех аспектов истинного документа HTML 4.0.
Интерпретатор SGML гарантирует, что синтаксис, структура, список элементов и их атрибутов соответствуют рекомендациям стандарта. Но он не может, например, обнаружить ошибки при установке атрибута ширины элемента IMG. Хотя спецификация ограничивает значение атрибута "целым числом пикселей"," DTD определяет только то, что это cdata, что практически допускает любые значения. Только специализированная программа способна выловить все несоответствия с HTML 4.0.
Несмотря ни на что, этот тип верификации является рекомендуемым, так как позволяет обнаружить большинство ошибок.
29.1. Каталог образцов SGML
Этот каталог включает в себя отвергнутые директивы с тем, чтобы гарантировать, что обрабатывающее программное обеспечение, такое как NSGMLS, использует предпочтительно общедоступные идентификаторы по отношению к системным идентификаторам. Это означает, что пользователи не должны быть подключены к сети при обработке системных идентификаторов, базирующихся на URI.
override yes
public "-//w3c//dtd html 4.0//en" strict.dtd
public "-//w3c//dtd html 4.0 transitional//en" loose.dtd
public "-//w3c//dtd html 4.0 frameset//en" frameset.dtd
public "-//w3c//entities latin1//en//html" htmllat1.ent
public "-//w3c//entities special//en//html" htmlspecial.ent
public "-//w3c//entities symbols//en//html" htmlsymbol.ent
29.2. sgml декларация html 4.0
Замечание. Набор символов SGML-деклараций документа включает в себя первые 17 плоскостей [ISO10646] (17 раз по 65536). Это ограничение связано с тем, что это число в текущей версии стандарта SGML имеет только 8 цифр.
Замечание. Строго говоря, регистрационный номер ISO 177 относится к исходному состоянию ISO 10646 в 1993 году, в то время как в этой спецификации мы базируемся на последней версии ISO 10646.
29.3. SGML декларация
<!sgml "ISO 8879:1986"
-- SGML - предложениеHhypertext Markup Language версия 4.0. С поддержкой первых 17 плоскостей ISO10646 и увеличенными пределами для меток и литералов. --
charset
baseset "ISO registration number 177//charset
ISO/IEC 10646-1:1993 UCS-4 with
implementation level 3//esc 2/5 2/15 4/6"
| descset | 0 | 9 | unused |
| 9 | 2 | 9 | |
| 11 | 2 | unused | |
| 13 | 1 | 13 | |
| 14 | 18 | unused | |
| 32 | 95 | 32 | |
| 127 | 1 | unused | |
| 128 | 32 | unused | |
| 160 | 55136 | 160 | |
| 55296 | 2048 | unused -- суррогаты -- | |
| 57344 | 1056768 | 57344 |
| capacity | sgmlref | |
| totalcap | 150000 | |
| grpcap | 150000 | |
| entcap | 150000 | |
| scope | document |
syntax
| shunchar | controls | 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 127
| baseset | "ISO 646irv:1991//charset | |
| international reference version (irv)//esc 2/8 4/2" |
descset 0 128 0
function
| re | 13 |
| rs | 10 |
| space | 32 |
| tab sepchar | 9 |
| naming | lcnmstrt "" | ||
| ucnmstrt "" | |||
| lcnmchar ".-_:" | |||
| ucnmchar ".-_:" | |||
| namecase | general | yes | |
| entity | no | ||
| delim | general | sgmlref | |
| shortref | sgmlref | ||
| names | sgmlref | ||
| quantity | sgmlref | ||
| attcnt | 60 | ||
| attsplen | 65536 | -- Это наибольшие величины -- | |
| litlen | 65536 | -- разрешенные в декларации -- | |
| namelen | 65536 | -- Избегайте фиксированных пределов -- | |
| pilen | 65536 | -- приложения агентов пользователя HTML -- | |
| taglvl | 100 | ||
| taglen | 65536 | ||
| grpgtcnt | 150 | ||
| grpcnt | 64 |
features
| minimize | ||
| datatag | no | |
| omittag | yes | |
| rank | no | |
| shorttag | yes | |
| link | ||
| simple | no | |
| implicit | no | |
| explicit | no | |
| other | ||
| concur | no | |
| subdoc | no | |
| formal | yes | |
| appinfo | none |
>
29.4. Определение типа документа DTD (Document Type Definition)
<!-- Это строгие DTD HTML 4.0, которые исключают новейшие презентационные атрибуты и элементы. Разработчикам следует пользоваться строгими требованиями DTD всюду, где возможно, но могут быть применены и переходные DTD там, где это требуется для презентационных атрибутов и элементов. HTML 4.0 включает в себя механизм стилевых листов, скриптов, встроенных объектов, улучшенную поддержку размещения текста слева на право и наоборот, усовершенствования в работе с формами, обеспечение доступа для людей с ограниченными возможностями.
Проект: $date: 1998/04/02 00:17:00 $
Авторы:
dave raggett <dsr@w3.org>
arnaud le hors <lehors@w3.org>
ian jacobs <ij@w3.org>
Дальнейшая информация об HTML 4.0 доступна по адресу:
http://www.w3.org/tr/rec-html40-->
<!-- Типовое применение:
| <!doctype html public "-//w3c//dtd html 4.0//en" | |
| "http://www.w3.org/tr/rec-html40/strict.dtd"> | |
| <html> | |
| <head> | |
| ... | |
| </head> | |
| <body> | |
| ... | |
| </body> | |
| </html> |
FPI для переходного HTML 4.0 dtd соответствует:
"-//w3c//DTD HTML 4.0 transitional//en"
а его uri:
http://www.w3.org/tr/rec-html40/loose.dtd
Если вы пишете документ, который включает в себя рамки, используйте fpi:
"-//w3c//dtd html 4.0 frameset//en"
с uri:
http://www.w3.org/tr/rec-html40/frameset.dtd
Следующие uri поддерживаются в рамках html 4.0
"http://www.w3.org/tr/rec-html40/strict.dtd" (strict dtd)
"http://www.w3.org/tr/rec-html40/loose.dtd" (loose dtd)
"http://www.w3.org/tr/rec-html40/frameset.dtd" (frameset dtd)
"http://www.w3.org/tr/rec-html40/htmllat1.ent" (latin-1 entities)
"http://www.w3.org/tr/rec-html40/htmlsymbol.ent" (symbol entities)
"http://www.w3.org/tr/rec-html40/htmlspecial.ent" (special entities)
Эти uri указывают на последние версии каждого из файлов. Для ссылок используйте URI:
"http://www.w3.org/tr/1998/rec-html40-19980424/strict.dtd"
"http://www.w3.org/tr/1998/rec-html40-19980424/loose.dtd"
"http://www.w3.org/tr/1998/rec-html40-19980424/frameset.dtd"
"http://www.w3.org/tr/1998/rec-html40-19980424/htmllat1.ent"
"http://www.w3.org/tr/1998/rec-html40-19980424/htmlsymbol.ent"
"http://www.w3.org/tr/1998/rec-html40-19980424/htmlspecial.ent"
-->
<!--================== Импортированные имена ===================== -- >
| <!entity % contenttype "cdata" | -- тип среды, как в rfc2045 --> |
<!entity % contenttypes "cdata"
-- список кодов типов среды, разделенных запятыми, в соответствие с [rfc-2045] -->
| <!entity % charset "cdata" | -- символьное кодирования как в [rfc-2045] --> |
| <!entity % charsets "cdata" | -- список символьных кодов, разделенных пробелами, как в rfc-2045 --> |
| <!entity % languagecode "name" | -- код языка, как в [RFC-1766] --> |
| <!entity % character "cdata" | -- одиночный символ из [ISO10646] --> |
| <!entity % linktypes "cdata" | -- список типов связей (через пробел) --> |
| <!entity % mediadesc "cdata" | -- список дескрипторов среды (через запятую)--> |
| <!entity % uri "cdata" | -- uri --> |
| <!entity % datetime "cdata" | -- информация о дате и времени. Формат ISO --> |
| <!entity % script "cdata" | -- скрипты --> |
| <!entity % stylesheet "cdata" | -- информация стилевого листа --> |
| <!entity % text "cdata"> |
<!-- parameter entities -->
<!entity % head.misc "script|style|meta|link|object" -- повторяющиеся элементы заголовков -->
<!entity % heading "h1|h2|h3|h4|h5|h6">
<!entity % list "ul | ol">
<!entity % preformatted "pre">
<!entity % color "cdata" -- цвет в представлении rgb: #rrggbb (hex формат) -->
<! -- Здесь представлены имена 16 широко известных цветов с их rgb значениями:
| black = | #000000 | green = | #008000 |
| silver = | #C0C0C0 | lime = | #00FF00 |
| gray = | #808080 | olive = | #808000 |
| white = | #FFFFFF | yellow = | #FFFF00 |
| maroon = | #800000 | navy = | #000080 |
| red = | #FF0000 | blue = | #0000FF |
| purple = | #800080 | teal = | #008080 |
| fuchsia = | #FF00FF | aqua = | #00FFFF |
--> <!entity % bodycolors "
| bgcolor %color; #implied | -- фоновый цвет документа -- |
| text %color; #implied | -- цвет текста документа -- |
| link %color; #implied | -- цвета связей -- |
| vlink %color; #implied | -- цвета посещенных URL -- |
| alink %color; #implied | -- цвет выбранного URL -- "> |
<!--============== Символьные мнемонические объекты ==============-->
<!entity % htmllat1 public
"-//w3c//entities latin1//en//html"
"http://www.w3.org/tr/1998/rec-html40-19980424/htmllat1.ent">
%htmllat1;
<!entity % htmlsymbol public
"-//w3c//entities symbols//en//html"
"http://www.w3.org/tr/1998/rec-html40-19980424/htmlsymbol.ent">
%htmlsymbol;
<!entity % htmlspecial public
"-//w3c//entities special//en//html"
"http://www.w3.org/tr/1998/rec-html40-19980424/htmlspecial.ent">
%htmlspecial;
<!--===================== Общие атрибуты =======================-->
<!entity % coreattrs
"id id #implied
-- уникальный идентификатор, действительный для всего документа --
| class cdata #implied | -- список классов, разделенных пробелами -- | |
| style %stylesheet; #implied | -- ассоциированная стилевая информация -- | |
| title %text; #implied | -- рекомендуемые заголовки /приложения --" > |
<!entity % i18n
| "lang %languagecode; #implied | -- код языка -- | |
| dir (ltr|rtl) #implied | -- направление для слабого/нейтрального текста --" > | |
| <!entity % events | ||
| "onclick %script; #implied | -- клавиша мышки была нажата -- | |
| ondblclick %script; #implied | -- клавиша мышки была нажата дважды -- | |
| onmousedown %script; #implied | -- клавиша мышки была нажата и удержана -- | |
| onmouseup %script; #implied | -- клавиша мышки была отпущена -- | |
| onmouseover %script; #implied | -- маркер был помещен на объект -- | |
| onmousemove %script; #implied | -- маркер перемещался в пределах объекта -- | |
| onmouseout %script; #implied | -- маркер удален с объекта -- | |
| onkeypress %script; #implied | -- клавиша была нажата и отпущена -- | |
| onkeydown %script; #implied | -- клавиша была зажата -- | |
| onkeyup %script; #implied | -- клавиша была отпущена --" > |
<!-- Зарезервированный переключатель функций -->
<!entity % html.reserved "ignore">
<!-- Следующие атрибуты зарезервированы для будущего использования -->
<![ %html.reserved; [
<!entity % reserved
| "datasrc %uri; #implied | -- a single or tabular data source -- | |
| datafld cdata #implied | -- свойство или имя колонки -- | |
| dataformatas (plaintext|html) plaintext | -- текст или html --" > |
]]>
<!entity % reserved "">
<!entity % attrs "%coreattrs; %i18n; %events;">
<!--================== Разметка текста (markup) ===================-->
<!entity % fontstyle "tt | i | b | big | small">
<!entity % phrase "em | strong | dfn | code |
samp | kbd | var | cite | abbr | acronym" >
<!entity % special
"a | img | object | br | script | map | q | sub | sup | span | bdo">
<!entity % formctrl "input | select | textarea | label | button">
<!-- %inline; охватывает строчные и "text-level" элементы -->
<!entity % inline "#pcdata | %fontstyle; | %phrase; | %special; | %formctrl;">
<!element (%fontstyle;|%phrase;) - - (%inline;)*>
<!attlist (%fontstyle;|%phrase;)
| %attrs; | -- %coreattrs, %i18n, %events -- > | |
| <!element (sub|sup) - - (%inline;)* | -- нижний или верхний индексы --> | |
| <!attlist (sub|sup) %attrs; | -- %coreattrs, %i18n, %events --> | |
| <!element span - - (%inline;)* | -- общий языковый/стилевой контейнер --> | |
| <!attlist span %attrs | -- %coreattrs, %i18n, %events -- | |
| %reserved | -- зарезервировано на будущее --> | |
| <!element bdo - - (%inline;)* | -- i18n bidi over-ride --> | |
| <!attlist bdo %coreattrs; | -- id, class, style, title -- | |
| lang %languagecode; #implied | -- код языка -- | |
| dir (ltr|rtl) #required | -- направление --> | |
| <!element br - o empty | -- принудительный разрыв строки --> | |
| <!attlist br %coreattrs; | -- id, class, style, title -- > | |
| <!element basefont - o empty | -- базовый размер шрифта --> | |
| <!attlist basefont | ||
| ID id #implied | -- идентификатор документа -- | |
| size cdata #required | -- базовый размер шрифта для элементов font -- | |
| color %color; #implied | -- цвет текста -- | |
| face cdata #implied | -- список имен шрифтов, разделенных запятыми -- > |
| <!element font - - (%inline;)* | -- локальная смена шрифта --> | |
| <!attlist font %coreattrs; | -- id, class, style, title -- | |
| %i18n; | -- lang, dir -- | |
| size cdata #implied | -- [+|-]nn e.g. size="+1", size="4" -- | |
| color %color; #implied | -- цвет текста -- | |
| face cdata #implied | -- список имен шрифтов, разделенных запятыми -- > |
<!--================ Модели содержимого html ==================-->
<!-- HTML имеет две базовые модели содержимого:
%inline; элементы символьного уровня и текстовые строки
%block; блочные элементы, напр., параграфы и списки -->
<!entity % block
"p | %heading; | %list; | %preformatted; | dl | div | noscript |
blockquote | form | hr | table | fieldset | address">
<!entity % flow "%block; | %inline;">
<!--=================== Тело документа ========================-->
<!element body o o (%block;|script)+ +(ins|del) -- тело документа -->
| <!attlist body %attrs; | -- %coreattrs, %i18n, %events -- | |
| onload %script; #implied | -- документ был загружен -- | |
| onunload %script; #implied | -- документ был удален --> | |
| <!element address - - (%inline;)* | -- информация об авторе --> | |
| <!attlist address %attrs; | -- %coreattrs, %i18n, %events -- > | |
| <!element div - - (%flow;)* | -- общий языковый/стилевой контейнер --> | |
| <!attlist div %attrs; | -- %coreattrs, %i18n, %events -- | |
| %reserved; | -- зарезервировано на будущее --> |
<!--================== Элемент anchor ========================-->
<!entity % shape "(rect|circle|poly|default)">
| <!entity % coords "cdata" | -- список длин с запятыми между элементами --> |
| <!element a - - (%inline;)* -(a) | -- якорь --> | |
| <!attlist a %attrs; | -- %coreattrs, %i18n, %events -- | |
| charset %charset; #implied | -- кодировка подключенного ресурса -- | |
| type %contenttype; #implied | -- рекомендуемый тип содержимого -- | |
| name cdata #implied | -- именованный конец связи -- | |
| href %uri; #implied | -- uri для связанного ресурса -- | |
| hreflang %languagecode; #implied | -- код языка -- | |
| rel %linktypes; #implied | -- прямые типы связи -- | |
| rev %linktypes; #implied | -- обратные типы связи -- | |
| target %frametarget; #implied | -- отображать в этой рамке -- | |
| accesskey %character; #implied | -- клавиша доступа -- | |
| shape %shape; rect | -- для использования с картой изображения клиента -- | |
| coords %coords; #implied | -- для использования с картой изображения клиента -- | |
| tabindex number #implied | -- индекс позиции в меню -- | |
| onfocus %script; #implied | -- элемент выделен -- | |
| onblur %script; #implied | -- элемент не выделен -- > |
<!--================ Карты изображения стороны клиента ==============-->
<!-- Они могут помещаться в один и тот же документ или группироваться в отдельном документе, хотя это и не поддерживается широко -->
| <!element map - - ((%block;)+ | area+) | -- карта изображения со стороны клиента --> |
<!attlist map
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| name cdata #required | -- для ссылок через карту использования -- > | |
| <!element area - o empty | -- карта изображения стороны клиента --> | |
| <!attlist area | ||
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| shape %shape; rect | -- управление интерпретацией координат -- | |
| coords %coords; #implied | -- список длин, разделенных запятыми -- | |
| href %uri; #implied | -- uri для подключенного ресурса -- | |
| target %frametarget; #implied | -- отображать в этой рамке -- | |
| nohref (nohref) #implied | -- эта область не производит действия -- | |
| alt %text; #required | -- краткое описание -- | |
| tabindex number #implied | -- положение при обходе меню -- | |
| accesskey %character; #implied | -- клавиша доступа -- | |
| onfocus %script; #implied | -- элемент выделен -- | |
| onblur %script; #implied | -- элемент не выделен -- > |
<!--===================== Элемент link ======================-->
<!-- Значения отношений могут использоваться:
для специальных меню (toolbars), когда значения отношений используются с элементом link в заголовке документа, напр., start, contents, previous, next, index, end, help
для связи с отдельным стилевым листом (rel=stylesheet)
для организации связи со скриптом (rel=script)
с стилевыми листами для управления процессом представления документов из нескольких узлов при их печати
для создания связи с печатаемой версией документа, напр., postscript или pdf (rel=alternate media=print) -->
| <!element link - o empty | -- связь, независящая от среды--> | |
| <!attlist link | ||
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| charset %charset; #implied | -- кодировка символов подключенного ресурса -- | |
| href %uri; #implied | -- uri для подключенного ресурса -- | |
| hreflang %languagecode; #implied | -- код языка -- | |
| type %contenttype; #implied | -- рекомендуемый тип содержимого -- | |
| rel %linktypes; #implied | -- прямые типы связей -- | |
| rev %linktypes; #implied | -- обратные типы связей -- | |
| media %mediadesc; #implied | -- для отображения в этих средах -- > | |
| target %frametarget; #implied | -- отображать в этой рамке -- > |
<!--===================== Изображения =====================-->
<!-- Длина, определенная в DTD, для cellpadding/cellspacing -->
| <!entity % length "cdata" | -- nn для пикселей или nn% для %-длины --> |
| <!entity % multilength "cdata" | -- пиксель, процент или относительно --> |
| <!entity % multilengths "cdata" | -- список multilength, разделенных запятыми --> |
| <!entity % pixels "cdata" | -- целочисленная длина в пикселях --> |
| <!entity % ialign "(top|middle|bottom|left|right)" | -- центрировать? --> |
<!-- Чтобы избежать проблем с агентами пользователя, ориентированными исключительно на работу с текстом, сделать изображение понятным и удобным для сетевого поиска для неграфических агентов пользователя, следует предусмотреть альтернативу описания с помощью alt, и избежать применения карт изображения на стороне сервера -->
| <!element img - o empty |
-- Встроенное изображение --> |
<!attlist img
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| src %uri; #required | -- uri встроенного изображения -- | |
| alt %text; #required | -- краткое описание -- | |
| longdesc %uri; #implied | -- связь с длинным описанием (complements alt) -- | |
| height %length; #implied | -- присвоение нового значения высоты -- | |
| width %length; #implied | -- присвоение нового значения ширины-- | |
| usemap %uri; #implied | -- для использования с картой изображения клиента -- | |
| ismap (ismap) #implied | -- для использования с картой изображения сервера --> | |
| align %ialign; #implied | -- вертикальное или горизонтальное выравнивание-- | |
| border %length; #implied | -- ширина границы для связи -- | |
| hspace %pixels; #implied | -- горизонтальный пробельный массив-- | |
| vspace %pixels; #implied | -- вертикальный пробельный массив-- > |
<!-- usemap указывает на элемент map, который может быть в этом документе или во внешнем документе, хотя последнее и не поддерживается широко -->
<!--==================== object ===================-->
<!-- object используется для вставления объектов в качестве части html страниц. Элементы param должны предшествовать остальному содержимому. -->
| <!element object - - (param | %flow;)* | -- общий встроенный объект --> |
<!attlist object
| %attrs | -- %coreattrs, %i18n, %events -- | |
| declare (declare) #implied | -- декларирует, но не инициирует флаг -- | |
| classid %uri; #implied | -- идентифицирует реализацию -- | |
| codebase %uri; #implied | -- базовый uri для classid, data, archive -- | |
| data %uri; #implied | -- ссылка на данные объекта -- | |
| type %contenttype; #implied | -- тип содержимого для данных -- | |
| codetype %contenttype; #implied | -- тип содержимого для кода -- | |
| archive %uri; #implied | -- архивный список с sp в качестве разделителей -- | |
| standby %text; #implied | -- сообщение, отображаемое при загрузке -- | |
| height %length; #implied | -- присваивает новое значение высоты -- | |
| width %length; #implied | -- присваивает новое значение ширины -- | |
| usemap %uri; #implied | -- для использования с картой изображения клиента -- | |
| name cdata #implied | -- представляет как часть формы -- | |
| tabindex number #implied | -- положение при обходе меню -- | |
| align %ialign; #implied | -- вертикальное или горизонтальное выравнивание-- | |
| border %length; #implied | -- ширина границы связи -- | |
| hspace %pixels; #implied | -- горизонтальный пробельный массив-- | |
| vspace %pixels; #implied | -- вертикальный пробельный массив-- | |
| %reserved; | -- зарезервировано на будущее --> |
| <!element param - o empty | -- именованное значение свойства --> |
align="justify"><!attlist param
| id id #implied | -- идентификатор документа -- | |
| name cdata #required | -- имя свойства -- | |
| value cdata #implied | -- значение свойства -- | |
| valuetype (data|ref|object) data | -- Как интерпретировать значение -- | |
| type %contenttype; #implied | -- тип содержимого для значения, когда valuetype=ref --> |
<!--======================= java applet ========================-->
<!-- Один из кодов или атрибутов объекта должен присутствовать. Помещайте элементы param до остального содержимого. -->
<!element applet - - (param | %flow;)* -- аплет java -->
| <!attlist applet %coreattrs; | -- id, class, style, title -- |
| codebase %uri; #implied | -- опционный базовый uri для аплета -- |
| archive cdata #implied | -- список архива с запятой в качестве разделителя-- |
| code cdata #implied | -- файл класса аплета -- |
| object cdata #implied | -- файл специального аплета -- |
| alt %text; #implied | -- краткое описание-- |
| name cdata #implied | -- позволяет аплетам найти друг друга -- |
| width %length; #required | -- начальная ширина -- |
| height %length; #required | -- начальная высота -- |
| align %ialign; #implied | -- вертикальное или горизонтальное выравнивание -- |
| hspace %pixels; #implied | -- горизонтальный пробельный массив-- |
| vspace %pixels; #implied | -- вертикальный пробельный массив-- > |
<!--================ Горизонтальная линейка ==================-->
| <!element hr - o empty | -- горизонтальная линейка --> | |
| <!attlist hr %coreattrs; | -- id, class, style, title -- | |
| %events; > |
<!--====================== Параграфы =======================-->
| <!element p - o (%inline;)* | -- параграф --> |
| <!attlist p %attrs; | -- %coreattrs, %i18n, %events -- > |
| %align; | -- выравнивание текста -- > |
<!--======================= Заголовки =======================-->
<!--Существует 6 уровней заголовков от H1 (наиболее важный) до H6 (наименее важный). -->
| <!element (%heading;) - - (%inline;)* | -- Заголовок --> |
| <!attlist (%heading;) %attrs; | -- %coreattrs, %i18n, %events -- > |
| %align; | -- выравнивание текста -- > |
<!--================ Преформатированный текст ================-->
<!-- не включает разметку для изображений и изменений в размере шрифтов -->
<!entity % pre.exclusion "img|object|big|small|sub|sup">
<!element pre - - (%inline;)* -(%pre.exclusion;) -- преформатированный текст -->
<!attlist pre %attrs; -- %coreattrs, %i18n, %events -- >
<!--===================== inline quotes ====================-->
| <!element q - - (%inline;)* | -- Кавычки для текста в пределах строки --> | |
| <!attlist q %attrs; | -- %coreattrs, %i18n, %events -- | |
| cite %uri; #implied | -- uri для исходного документа или сообщения -- > |
<!--===================== block-like quotes ====================-->
<!element blockquote - - (%block;|script)+ -- Кавычки для многострочных блоков текста -->
<!attlist blockquote
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| cite %uri; #implied | -- uri для исходного документа или сообщения --> |
<!--================== Введенный/Стертый текст ====================-->
<!-- ins/del are handled by inclusion on body -->
| <!element (ins|del) - - (%flow;)* | -- введенный текст, стертый текст --> | |
| <!attlist (ins|del) %attrs; | -- %coreattrs, %i18n, %events -- | |
| cite %uri; #implied | -- инфо о причине изменения -- | |
| datetime %DAtetime; #implied | -- дата и время изменения -- > |
<!--====================== Списки ========================-->
<!-- список определений - dt - для термов, dd - для их определений -->
| <!element dl - - (dt|dd)+ | -- список определений --> |
| <!attlist dl %attrs; | -- %coreattrs, %i18n, %events --> |
| <!element dt - o (%inline;)* | -- term определения --> |
| <!element dd - o (%flow;)* | -- описание определения --> |
| <!attlist (dt|dd) %attrs; | -- %coreattrs, %i18n, %events --> |
| <!element ol - - (li)+ | -- упорядоченный список --> |
| <!attlist ol %attrs; | -- %coreattrs, %i18n, %events --> |
<!-- Стиль нумерации упорядоченных списков (ol)
1 арабские числа 1, 2, 3, ...
a строчные буквы a, b, c, ...
a прописные буквы a, b, c, ...
i строчные римские i, ii, iii, ...
i прописные римские i, ii, iii, ...
Стиль применяется к номеру по порядку, который по умолчанию равен 1 для первого элемента упорядоченного списка. -->
<!entity % olstyle "cdata" -- ограничено перечнем: "(1|a|a|i|i)" -->
<!element ol - - (li)+ -- упорядоченный список -->
<!attlist ol
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| type %olstyle; #implied | -- стиль нумерации -- | |
| compact (compact) #implied | -- уменьшенный зазор между позициями-- | |
| start number #implied | -- начальный номер последовательности -- > |
<!-- Неупорядоченные списки (ul) bullet styles -->
| <!element ul - - (li)+ | -- неупорядоченный список --> |
| <!attlist ul %attrs; | -- %coreattrs, %i18n, %events -- > |
| <!element li - o (%flow;)* | -- элемент списка --> |
| <!attlist li %attrs; | -- %coreattrs, %i18n, %events -- > |
| type %ulstyle; #implied | -- стиль bullet -- | |
| compact (compact) #implied | -- уменьшенный зазор между позициями-- > |
<!--==================== Формы =======================-->
| ><!element form - - (%block;|script)+ -(form) |
-- интерактивная форма --> |
| <!attlist form %attrs; | -- %coreattrs, %i18n, %events -- | |
| action %uri; #required | -- хандлер форм для стороны сервера -- | |
| method (get|post) get | -- http метод для представления форм -- | |
| enctype %contenttype; "application/x-www-form-urlencoded" | ||
| onsubmit %script; #implied | -- форма была представлена -- | |
| onreset %script; #implied | -- форма возвращена в исходное состояние -- | |
| target %frametarget; #implied | -- отображать в этой рамке -- | |
| accept-charset %charsets; #implied | -- список поддерживаемых символьных наборов -- > |
<!-- Каждая метка не должна содержать более одного поля -->
<!element label - - (%inline;)* -(label) -- текст метки поля формы -->
| <!attlist label %attrs; | -- %coreattrs, %i18n, %events -- | |
| or idref #implied | -- проверяет корректность значения поля -- | |
| accesskey %character; #implied | -- клавиша доступа -- | |
| onfocus %script; #implied | -- элемент выделен -- | |
| onblur %script; #implied | -- элемент не выделен -- > |
<!entity % inputtype
"(text | password | checkbox | radio | submit | reset | file | hidden | image | button)" >
<!-- имя атрибута необходимо всем кроме submit & reset -->
| <!element input - o empty | -- Управление формой --> | |
| <!attlist input %attrs; | -- %coreattrs, %i18n, %events -- | |
| type %inputtype; text | -- what kind of widget is needed -- | |
| name cdata #implied | -- представить в качестве части формы -- | |
| value cdata #implied | -- необходимо для радио кнопок и переключателей -- | |
| checked (checked) #implied | -- для радио кнопок и переключателей -- | |
| disabled (disabled) #implied | -- недоступно в данном контексте -- | |
| readonly (readonly) #implied | -- для текста и пароля -- | |
| size cdata #implied | -- разный для каждого из полей -- | |
| maxlength number #implied | -- максимальное число символов для текстовых полей -- | |
| src %uri; #implied | -- для полей с изображением -- | |
| alt cdata #implied | -- краткое описание -- | |
| usemap %uri; #implied | -- использует карту изображения клиента -- | |
| tabindex number #implied | -- номер позиции в меню -- | |
| accesskey %character; #implied | -- клавиша доступа -- | |
| onfocus %script; #implied | -- элемент выделен -- | |
| onblur %script; #implied | -- элемент не выделен -- | |
| onselect %script; #implied | -- некоторая часть текста выделена -- | |
| onchange %script; #implied | -- значение элемента изменилось -- | |
| accept %contenttypes; #implied | -- список типов mime для файловой загрузки -- | |
| align %ialign; #implied | -- вертикальное или горизонтальное выравнивание-- | |
| %reserved; | -- зарезервировано на будущее -- > |
| <!element select - - (optgroup|option)+ | -- селектор опций --> | |
| <!attlist select %attrs; | -- %coreattrs, %i18n, %events -- | |
| name cdata #implied | -- имя поля -- | |
| size number #implied | -- видимые строки -- | |
| multiple (multiple) #implied | -- по умолчанию один выбор -- | |
| disabled (disabled) #implied | -- недоступно в данном контексте -- | |
| tabindex number #implied | -- номер позиции в меню -- | |
| onfocus %script; #implied | -- элемент выделен -- | |
| onblur %script; #implied | -- элемент не выделен -- | |
| onchange %script; #implied | -- значение элемента изменилось -- | |
| %reserved; | -- зарезервировано на будущее -- > |
| <!element optgroup - - (option)+ | -- группа опций --> | |
| <!attlist optgroup %attrs; | -- %coreattrs, %i18n, %events -- | |
| disabled (disabled) #implied | -- недоступно в данном контексте -- | |
| label %text; #required | -- для использования в иерархических меню --> |
| <!element option - o (#pcdata) | -- селективный выбор --> | |
| <!attlist option %attrs; | -- %coreattrs, %i18n, %events -- | |
| selected (selected) #implied | ||
| disabled (disabled) #implied | -- недоступно в данном контексте -- | |
| label %text; #implied | -- для использования в иерархических меню -- | |
| value cdata #implied | -- значения по умолчанию содержимого элемента --> |
| <!element textarea - - (#pcdata) | -- многострочное текстовое поле --> |
| <!attlist textarea %attrs; | -- %coreattrs, %i18n, %events -- | |
| name cdata #implied | ||
| rows number #required | ||
| cols number #required | ||
| disabled (disabled) #implied | -- недоступно в данном контексте -- | |
| readonly (readonly) #implied | ||
| tabindex number #implied | -- номер позиции в меню -- | |
| accesskey %character; #implied | -- клавиша доступа -- | |
| onfocus %script; #implied | -- элемент выделен -- | |
| onblur %script; #implied | -- элемент не выделен -- | |
| onselect %script; #implied | -- некоторая часть текста выделена -- | |
| onchange %script; #implied | -- значение элемента изменилось -- | |
| %reserved; | -- зарезервировано на будущее --> |
<!-- #pcdata служит для решения проблем смешанного содержимого, в спецификации допустим только пробел! -->
| <!element fieldset - - (#pcdata,legend,(%flow;)*) | -- группа управлений формой --> | |
| <!attlist fieldset %attrs; | -- %coreattrs, %i18n, %events -- > | |
| <!element legend - - (%inline;)* | -- легенда поля --> | |
| <!entity % lalign "(top|bottom|left|right)"> | -- выравнивание --> | |
| <!attlist legend %attrs; | -- %coreattrs, %i18n, %events -- | |
| accesskey %character; #implied | -- клавиша доступа -- > |
<!element button - - (%flow;)* -(a|%formctrl;|form|fieldset)
-- кнопка нажатия -->
| <!attlist button %attrs; | -- %coreattrs, %i18n, %events -- | |
| name cdata #implied | ||
| value cdata #implied | -- посылается серверу при представлении -- | |
| type (button|submit|reset) submit | -- для использования в качестве кнопки в форме -- | |
| disabled (disabled) #implied | -- не доступно в данном контексте -- | |
| tabindex number #implied | -- номер позиции в меню -- | |
| accesskey %character; #implied | -- клавиша доступа -- | |
| onfocus %script; #implied | -- элемент выделен -- | |
| onblur %script; #implied | -- элемент не выделен -- | |
| %reserved; | -- зарезервировано на будущее -- > |
<!--===================== Таблицы ======================-->
<!-- Стандарт таблиц ietf HTML, см. [rfc-1942] -->
<!-- Атрибут border устанавливает толщину рамки вокруг таблицы. Единицы измерения по умолчанию пиксели. Атрибут frame специфицирует то, какую часть рамки вокруг таблицы следует отображать. Значение "border" включено для обеспечения обратной совместимости с <table border>, который выдает frame=border и border=implied. Для <table border=1> вы получите border=1 и frame=implied. В этом случае, представляется разумным считать, что frame=border для обратной совместимости с уже существующими броузерами. -->
<!entity % tframe "(void|above|below|hsides|lhs|rhs|vsides|box|border)">
<!-- Атрибут rules определяет, какие линии должны быть проведены между ячейками:
Если rules отсутствуют, то предполагается:
"none", если border отсутствует или =0, в противном случае "all" -->
<!entity % trules "(none | groups | rows | cols | all)">
<!-- горизонтальное размещение таблицы в документе -->
<!entity % talign "(left|center|right)">
<!-- Атрибуты горизонтального выравнивания для содержимого ячеек -->
<!entity % cellhalign "align (left|center|right|justify|char) #implied
| char %character; #implied | -- символ выравнивания, напр. символ=':' -- | |
| charoff %length; #implied | -- смещение символа выравнивания --" > |
<!-- атрибуты вертикального выравнивания для содержимого -->
<!entity % cellvalign "valign (top|middle|bottom|baseline) #implied" >
<!element table - -
(caption?, (col*|colgroup*), thead?, tfoot?, tbody+)>
| <!element caption - - (%inline;)* | -- Название таблицы --> |
| <!element thead - o (tr)+ | -- Заголовок таблицы --> |
| <!element tfoot - o (tr)+ | -- Подпись под таблицей --> |
| <!element tbody o o (tr)+ | -- Тело таблицы --> |
| <!element colgroup - o (col)* | -- Группа колонок таблицы --> |
| <!element col - o empty | -- Колонка таблицы --> |
| <!element tr - o (th|td)+ | -- Строка таблицы --> |
| <!element (th|td) - o (%flow;)* | -- Заголовок ячейки, данные ячейки таблицы --> |
| <!attlist table | -- Элемент таблицы -- | |
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| summary %text; #implied | -- цель/структура для речевого вывода -- | |
| width %length; #implied | -- ширина таблицы -- | |
| border %pixels; #implied | -- управляет шириной рамки вокруг таблицы -- | |
| frame %tframe; #implied | -- какую часть таблицы отображать-- | |
| rules %trules; #implied | -- линии между строками и колонками -- | |
| cellspacing %length; #implied | -- зазор между ячейками -- | |
| cellpadding %length; #implied | -- зазор внутри ячеек -- | |
| align %talign; #implied | -- положение таблицы по отношению к окну -- | |
| bgcolor %color; #implied | -- фоновый цвет ячеек таблицы -- | |
| %reserved; | -- зарезервировано на будущее -- | |
| datapagesize cdata #implied | -- зарезервировано на будущее -- > |
<!entity % calign "(top|bottom|left|right)">
| <!attlist caption %attrs; | -- %coreattrs, %i18n, %events -- > |
<!-- Элемент colgroup группирует набор элементов col. Он позволяет сгруппировать несколько семантически зависимых колонок вместе. -->
| <!attlist colgroup %attrs; | -- %coreattrs, %i18n, %events -- | |
| span number 1 | -- число колонок в группе по умолчанию -- | |
| width %multilength; #implied | -- значение ширины по умолчанию для вложенных col -- | |
| %CEllhalign; | -- горизонтальное выравнивание в ячейках -- | |
| %CEllvalign; | -- вертикальное выравнивание в ячейках -- > |
<!-- Элементы col определяют свойства выравнивания для ячеек в одной или нескольких колонках.
Атрибут width специфицирует ширину колонок, напр.
| width=64 | ширина в пикселях |
| width=0.5* | относительная ширина 0.5 |
Атрибут span заставляет атрибуты одного элемента col работать для нескольких колонок. -->
| <!attlist col | -- группы колонок и свойства -- | |
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| span number 1 | -- атрибуты col воздействуют на n колонок -- | |
| width %multilength; #implied | -- спецификация ширины колонки -- | |
| %CEllhalign; | -- горизонтальное выравнивание в ячейках -- | |
| %CEllvalign; | -- вертикальное выравнивание в ячейках -- > |
<!-- Используйте thead для дублирования заголовков при продолжении таблицы на нескольких страницах, или для статического заголовка для секций tbody со скролированием.
Используйте tfoot для дублирования подписи под таблицей при продолжении таблицы на нескольких страницах, или для статического заголовка для секций tbody со скролированием.
Используйте секции tbody, когда необходимы разделительные линии между группами строк в таблице. -->
| <!attlist (thead|tbody|tfoot) | -- секция таблицы -- | |
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| %CEllhalign; | -- горизонтальное выравнивание в ячейках-- | |
| %CEllvalign; | -- вертикальное выравнивание в ячейках -- > |
| <!attlist tr | -- строка таблицы -- | |
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| %CEllhalign; | -- горизонтальное выравнивание в ячейках -- | |
| %CEllvalign; | -- вертикальное выравнивание в ячейках -- > | |
| bgcolor %color; #implied | -- цвет фона для строки -- > |
<!-- scope проще, чем осевые атрибуты для обычных таблиц -->
<!entity % scope "(row|col|rowgroup|colgroup)">
<!-- th для заголовков, td для данных a, но для ячеек используется td -->
| <!attlist (th|td) | -- заголовок или данные ячейки -- | |
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| abbr %text; #implied | -- сокращение для ячейки заголовка -- | |
| axis cdata #implied | -- имена групп связанных заголовков -- | |
| headers idrefs #implied | -- список id для ячеек заголовка | |
| scope %scope; #implied | -- область, перекрываемая ячеками заголовка -- | |
| rowspan number 1 | -- число строк в ячейке -- | |
| colspan number 1 | -- число колонок в ячейке -- | |
| %CEllhalign; | -- горизонтальное выравнивание в ячейках -- | |
| %CEllvalign; | -- вертикальное выравнивание в ячейках -- > | |
| nowrap (nowrap) #implied | -- подавление разрыва слов -- | |
| bgcolor %color; #implied | -- цвет фона ячейки -- | |
| width %pixels; #implied | -- ширина ячейки -- | |
| height %pixels; #implied | -- высота ячейки -- > |
<!--=================== Рамки документа ====================-->
<!-- Модель содержимого для HTML- документа зависит от того, следует ли за head элемент frameset или body. Широко распространенное отсутствие начальной метки body делает непрактичным определение модели содержимого без использования помеченной секции. -->
<!-- Переключатель функций для набора рамок документов -->
<!entity % html.frameset "ignore">
<![ %html.frameset; [
<!element frameset - - ((frameset|frame)+ & noframes?) – разделение окна -->
| <!attlist frameset %coreattrs; | -- id, class, style, title -- |
| rows %multilengths; #implied | -- список длин, по умолчанию 100% (1 строка) -- |
| cols %multilengths; #implied | -- список длин, по умолчанию 100% (1 колонка) -- |
| onload %script; #implied | -- все рамки были загружены -- |
| onunload %script; #implied | -- все рамки удалены -- > |
]]>
<![ %html.frameset; [
<!-- резервные имена рамок начинаются с "_" в противном случае с буквы -->
<!element frame - o empty -- субокно -->
<!attlist frame
| %coreattrs; | -- id, class, style, title -- |
| longdesc %uri; #implied | -- указатель на длинное описание (complements title) -- |
| name cdata #implied | -- имя рамки для обращений -- |
| src %uri; #implied | -- источник содержимого рамки -- |
| frameborder (1|0) 1 | -- запрос границ рамки? -- |
| marginwidth %pixels; #implied | -- ширины полей в пикселях -- |
| marginheight %pixels; #implied | -- высота поля в пикселях -- |
| noresize (noresize) #implied | -- разрешить пользователям изменить размер рамок? -- |
| scrolling (yes|no|auto) auto | -- есть или нет полоса прокрутки -- > |
]]>
<!element iframe - - (%flow;)* -- inline subwindow -->
<!attlist iframe %coreattrs; -- id, class, style, title --
| longdesc %uri; #implied | -- указатель на длинное описание -- |
| name cdata #implied | -- имя рамки для обращений -- |
| src %uri; #implied | -- источник содержимого рамки -- |
| frameborder (1|0) 1 | -- запрос границ рамки? -- |
| marginwidth %pixels; #implied | -- ширины полей в пикселях -- |
| marginheight %pixels; #implied | -- высота поля в пикселях -- |
| scrolling (yes|no|auto) auto | -- есть или нет полоса прокрутки -- |
| align %ialign; #implied | -- вертикальное или горизонтальное выравнивание-- |
| height %length; #implied | -- высота рамки -- |
| width %length; #implied | -- ширина рамки -- > |
<![ %html.frameset; [
<!entity % noframes.content "(body) -(noframes)">
]]>
<!entity % noframes.content "(%flow;)*">
<!element noframes - - %noframes.content;
< -- контейнер альтернативного сообщения для отображения без поддержки рамок -->
<!attlist noframes %attrs; -- %coreattrs, %i18n, %events -- >
<!--================== Заголовок документа ==================-->
<!-- %head.misc; определены ранее как "script|style|meta|link|object" -->
<!entity % head.content "title & base?">
<!element head o o (%head.content;) +(%head.misc;) -- Заголовок документа -->
| <!attlist head %i18n; | lang, dir | |
| profile %uri; #implied | -- именованный словарь мета инфо -- > |
<!-- Элемент title не рассматривается как часть текста. Он должен быть отображен, например, как заголовок страницы или окна. У документа должен быть только один заголовок. -->
<!element title - - (#pcdata) -(%head.misc;) -- заголовок документа -->
<!attlist title %i18n>
<!element isindex - o empty -- однострочное сообщение – подсказка -->
<!attlist isindex
| %coreattrs; | -- id, class, style, title -- |
| %i18n; | -- lang, dir -- |
| prompt %text; #implied | -- сообщение-подсказка --> |
<!element base - o empty -- базовый uri документа -->
<!attlist base href %uri; #required -- uri, выполняющий функцию базового идентификатора -- >
| target %frametarget; #implied | -- отображать в этой рамке -- > |
| <!element meta - o empty | -- общая метаинформация --> |
| <!attlist meta %i18n; | -- lang, dir, для использования с содержимым -- |
| http-equiv name #implied | -- имя заголовка http отклика -- |
| name name #implied | -- имя метаинформации -- |
| content cdata #required | -- ассоциированная информация -- |
| scheme cdata #implied | -- выбранная форма содержимого -- > |
| <!element style - - %stylesheet | -- стилевое инфо --> | |
| <!attlist style %i18n; | -- lang, dir, для использования в заголовке -- | |
| type %contenttype; #required | -- тип содержимого стилевого языка -- | |
| media %mediadesc; #implied | -- предназначено для работы с этими средами -- | |
| title %text; #implied | -- рекомендуемый title -- > |
<!element script - - %script; -- декларации скрипта -->
<!attlist script charset %charset; #implied -- символьное кодирование подключенного ресурса --
| type %contenttype; #required | -- тип содержимого языка скрипта -- |
| language cdata #implied | -- предопределенное имя языка скрипта -- |
| src %uri; #implied | -- uri внешнего скрипта -- |
| defer (defer) #implied | -- ua может отложить исполнение скрипта -- |
| event cdata #implied | -- зарезервировано на будущее -- |
| for %uri; #implied | -- зарезервировано на будущее -- > |
<!element noscript - - (%block;)+ -- альтернативный текст для случая отображения без поддержки скриптов -->
<!attlist noscript %attrs; -- %coreattrs, %i18n, %events -- >
<!--================== Структура документа ===================-->
<!entity % version "version cdata #fixed '%html.version;`">
<!entity % html.content "head, body">
<!element html o o (%html.content;) -- корневой элемент документа -->
<!attlist html %i18n; -- lang, dir -- >
30. Определение типа документа frameset
<!-- Это HTML 4.0 frameset DTD, который должен использоваться для документов с рамками. Этот DTD идентичен переходному DTD HTML 4.0 за исключением модели содержимого "html" элемента: в документах с рамками, элемент "frameset" замещает элемент "body".
Дополнительная информация о HTML 4.0 доступна по адресу:
www.w3.org/tr/rec-html40. -->
<!entity % html.version "-//w3c//dtd HTML 4.0 frameset//en" -- Типовое использование:
<!doctype html public "-//w3c//dtd html 4.0 frameset//en"
"http://www.w3.org/tr/rec-html40/frameset.dtd">
<html>
<head>
...
</head>
<frameset>
...
</frameset>
</html>
-->
<!entity % html.frameset "include">
<!entity % html4.dtd public "-//w3c//dtd html 4.0 transitional//en">
%html4.dtd;
31. Эталонные символьные объекты в HTML 4.0
31.1. Введение
Эталонные символьные объекты представляют собой SGML конструкцию, которая соответствует набору символов документа. Эта версия HTML поддерживает несколько наборов эталонных последовательностей символов:
Символы ISO 8859-1 (Latin-1). В соответствии с секцией 14 RFC-1866, набор Latin-1 был расширен с тем, чтобы покрыть всю правую часть ISO-8859-1 (все позиции кодов с 1 в старшем бите), включая широко используемые , © и ®. Имена символьных объектов взяты из приложений SGML (определено в ISO8879).
Символы, математические символы и греческие буквы. Эти символы могут быть представлены глифами в шрифте adobe "symbol".
Символы разметки (markup) и символы интернационализации (напр., для двунаправленного текста).
Следующие разделы представляют собой полные списки эталонных символьных объектов. Хотя по соглашению ISO10646 комментарии пишутся большими буквами, мы для целей лучшей читаемости преобразовали их в строчные.
31.2. Эталонные символьные объекты для символов ISO 8859-1
Эталонные символьные объекты в этой секции формируют символы, чьи цифровые эквиваленты должны поддерживаться агентами пользователя HTML 2.0. Таким образом, эталонный символьный объект ÷ более удобная форма, чем ÷ для получения знака деления (/).
Чтобы поддержать эти именованные объекты агенты пользователя должны только распознать имя объекта и преобразовать его в символ из таблицы ISO88591.
Символ 65533 (FFFD в шестнадцатеричной нотации) является последним допустимым символом в UCS-2. 65534 (fffe в шестнадцатеричной нотации) не имеет какого-либо соответствия и зарезервирован для "неразрывного пробела нулевой ширины" для целей детектирования порядка байт. 65535 (FFFF в шестнадцатеричной нотации) вообще не имеет смысла.
32. Приложение А
Отличия html 3.2 и html 4.0
Изменения в элементах
Новые элементы
Новыми элементами в HTML 4.0 являются: abbr, acronym, bdo, button, col, colgroup, del, fieldset, frame, frameset, iframe, ins, label, legend, noframes, noscript, object, optgroup, param, s (не рекомендуемый), span, tbody, tfoot, thead и q.
Не рекомендуемые элементы
Следующие элементы являются не рекомендуемыми: applet, basefont, center, dir, font, isindex, menu, strike и u.
Устаревшие элементы
Следующие элементы являются устаревшими: listing, plaintext, и xmp. Вместо них разработчикам следует использовать элемент pre.
Изменения в атрибутах
Почти все атрибуты, которые специфицируют представление HTML-документа (напр., colors, alignment, fonts, graphics, и т.д.) объявлены не рекомендуемыми, предпочтение отдается стилевым листам.
Атрибуты id и class позволяют разработчику присвоить имя и класс информации элементам для стилевых листов, для скриптов, для деклараций объектов и т.д..
Изменения в доступе
В HTML 4.0 введено много изменений для обеспечения доступа, включая:
Атрибут title может быть теперь установлен почти для любого элемента.
Разработчик может выдавать длинные описания таблиц, изображений и рамок.
Изменения для мета данных
Разработчики могут теперь специфицировать профайлы, которые выдают объяснения по поводу мета данных, заданных элементами meta или link.
Изменения для текста
Новые возможности интернационализации позволяют разработчикам специфицировать язык документа и направление текста.
Элементы ins и del позволяют разработчикам помечать изменения, внесенные в документ.
Элементы ABBR и acronym позволяют разработчикам помечать сокращения и акронимы в своих документах.
Изменения для связей
Атрибут ID делает любой элемент якорем назначения связи.
Изменения для таблиц
Модель таблиц HTML 4.0 выросла из более ранней концепции HTML+ и первоначального проекта HTML 3.0. Предыдущая модель была расширена в ответ на следующие запросы от информационных провайдеров:
Разработчики могут специфицировать таблицы, которые отображаются агентом пользователя по мере получения данных.
Разработчики могут специфицировать таблицы, которые доступны пользователям с не визуальными агентами пользователя.
Разработчики могут специфицировать таблицы, с фиксированными заголовками и подписями. Агенты пользователя могут использовать преимущества этого решения при скролировании больших таблиц или при отображении таблиц в многостраничном формате.
Модель таблиц HTML 4. 0 удовлетворяет требованиям опционного выравнивания по колонкам, предоставляется больше гибкости при спецификации рамок и разделительных линий в таблицах. Ожидается, однако, что стилевые листы в самом ближайшем будущем возьмут на себя функции формирования и таблиц.
Кроме того главной целью является обеспечение обратной совместимости с широко распространенными приложениями таблиц Netscape. Другой целью было упрощение импорта таблиц совместимых с моделью SGML cals. Последний проект делает атрибут выравнивания совместимым с последней версией наиболее популярных броузеров.
Для формирования групп колонок с различной шириной и свойствами выравнивания введен новый элемент colgroup, который может работать с одним или более элементов col.
Стилевой атрибут включен как средство расширения свойств, связанных с краями внутренней области групп ячеек. Например, стиль линии: точечная, двойная, тонкая/толстая и т.д.; цвет заполнения внутренней области; поля ячейки и шрифты.
Атрибуты рамки и разделительных линий модифицированы для исключения конфликтов имен с sgml, а также для блокировки влияния совпадения имен атрибутов align и valign. Эти изменения стимулировались желанием исключить в будущем проблемы, если спецификация будет расширена и разрешит применение атрибутов рамок и разделительных линий другими элементами таблицы.
Изменения для изображений, объектов и карт изображений
Элемент object позволяет включать объекты.
Элементы iframe и object позволяют разработчикам создавать встраиваемые документы.
Атрибут alt необходим для элементов img и area.
Механизм создания карт изображения позволяет разработчикам создавать более доступные карты. Модель содержимого элемента map по этой причине была изменена.
Изменения для форм
Данная спецификация вводит несколько новых атрибутов и элементов, для работы с формами:
Атрибут ключа доступа позволяет разработчику специфицировать прямой доступ к управлению формой через клавиатуру.
Атрибут disabled позволяет разработчику сделать управление формой заблокированным.
Атрибут readonly позволяет разработчику запретить какие-либо изменения в управлении формой.
Элемент label устанавливает связь между меткой и конкретным видом управления формой.
Элемент fieldset группирует связанные по смыслу поля в соответствии элементом legend. Оба эти новые элемента позволяют лучше организовать процесс отображения и улучшить интерактивность. Броузеры, ориентированные на воспроизведение речи при описании формы могут учитывать, вводимые этими элементами метки (ярлыки).
Новый набор атрибутов в сочетании со скриптами позволяют разработчику форм верифицировать данные, вводимые пользователем.
Элементы button и input с типом "button" могут использоваться в комбинации со скриптами для существенного обогащения возможностей форм.
Элемент optgroup позволяет разработчику группировать опции в меню select, который весьма важен для обеспечения доступа к форме. Дополнительные изменения для интернационализации.
Изменения для стилевых листов
HTML 4.0 поддерживает больший набор описателей среды, так что разработчики могут писать стилевые листы, ориентированные на определенные внешние устройства.
Изменения для рамок
HTML 4.0 поддерживает документы со встроенными рамками.
Изменения для скриптов
Многие элементы имеют атрибуты событий, которые сопряжены со скриптами, исполняемыми при наступлении такого события (напр., при загрузке документа, при нажатии клавиши мышки и т.д.).
Изменения для интернационализации
HTML 4.0 интегрирует рекомендации RFC-2070 для интернационализации HTML.
Однако, эта спецификация и RFC-2070 отличаются в следующих пунктах:
Атрибут accept-charset был специфицирован скорее для элемента form, чем для textarea и input.
Спецификация HTML 4.0 дает дополнительные разъяснения для двунаправленных алгоритмов укладки текста.
Использование cdata для определения элементов script и style не сохраняет возможности перекодировки документа, как это описано в RFC-2070.
33. Приложение b
Рабочие характеристики, приложения и заметки для разработчиков.
Следующие замечания являются информативными, а не нормативными.
33.1. Замечания по поводу некорректных документов
Эта спецификация не определяет, как агент пользователя должен обрабатывать случаи ошибок, включая то, как агент пользователя должен себя вести, встретив элемент, атрибут, значение атрибута или объект, не специфицированный в данном документе.
Однако, для облегчения экспериментов и взаимосогласованности между различными приложениями разных версий HTML, рекомендуется следующее:
Если агент пользователя встретил незнакомый элемент, он должен попытаться отобразить (render) его содержимое.
Если агент пользователя встретил незнакомый атрибут, он должен его игнорировать всю спецификацию этого атрибута (напр., атрибут и его значение).
Если агент пользователя встретил незнакомое значение атрибута, он должен использовать значение атрибута по умолчанию.
Если он встретил не декларированный объект, объект должен восприниматься как символьная информация.
Рекомендуется также, чтобы агенты пользователя обеспечивали информирование пользователя о перечисленных выше случаях.
Так как агенты пользователя могут реагировать на ошибки по-разному разработчики и пользователи не должны предполагать какое-то определенное поведение системы при столкновении с ошибкой.
Спецификация HTML 2.0 (RFC-1866) предполагает, что многие агенты пользователя HTML 2.0 считают, что документы, не начинающиеся с декларации типа, являются документами HTML 2.0. Как показывает практика, это плохое предположение, данная спецификация не рекомендует такое поведение агентов пользователя.
Для целей совместимости разработчики не должны "расширять" HTML за пределы доступных механизмов SGML (напр., расширяя DTD, добавляя новые наборы объектов, и т.д.).
34. Специальные символы в значениях атрибута uri
34.1. Не-ASCII символы в значениях атрибута URL
Хотя URI не содержат не-ASCII значений, разработчики иногда специфицируют их в атрибутах, где должен лежать URI (напр., определенные с помощью %uri в DTD).
Например, следующее значение Href нелегально:
<a href="http://foo.org/hakon">...</a>
Рекомендуется, чтобы агент пользователя воспринял следующее соглашение для обработки не-ASCII символов в следующих случаях:
Представлять каждый символ в UTF-8 (см. RFC-2044) как один или более байт.
Обходить эти байты с помощью механизма URI (напр., путем конверсии каждого байта в %HH, где HH представляет собой шестнадцатеричное представление значения байта).
Эта процедура выдает в результате синтаксически корректный uri (как это определено в RFC-1738, секция 2.2 или RFC-2141, секция 2), это не зависит от метода кодировки символов.
Замечание. Некоторые старые агенты пользователя обрабатывают URI в HTML тривиально, используя байты символов в том виде, в котором они записаны в документе. Некоторые старые HTML-документы полагаются на эту практику и прерывают свою работы при перекодировке (transcode). Агенты пользователя, которые хотят работать с этими старыми документами должны при получении URI, содержащего нестандартные символы, сначала использовать преобразование, базирующееся на UTF-8. Только если полученное в результате URI не удается распознать, они должны попробовать сформировать URI, базируясь на байтах символов в кодировке полученного документа.
Замечание. То же самое преобразование, базирующееся на UTF-8 должно быть применено к значениям атрибутов имен для элемента A.
34.2. Символ & в значениях атрибута URI
URI, который создан при выдаче формы, может быть использован в качестве связи типа якорь (напр., атрибут Href для элемента A). К сожалению использование символа "&" для разделения полей формы противоречит его применению в значениях атрибутов SGML для выделения символьных объектов. Например, для того чтобы использовать URI "http://host/?x=1&y=2" в качестве связующего URI, его следует записать в виде <a Href="http://host/?x=1&y=2"> или <a Href="http://host/?x=1&y=2">.
Рекомендуется, чтобы пользователи сервера http, и в частности, пользователи CGI поддерживали применение ";" вместо "&" с целью избавления разработчиков от обхода символов "&".
35. Замечания об использовании sgml
Разрывы строк
SGML специфицирует то, что разрыв строки сразу после начальной метки должен игнорироваться, также как и разрыв строки непосредственно перед конечной меткой. Это приложимо ко всем HTML-элементам без исключения. Следующие два HTML-примера должны отображаться идентично:
<p> Томас смотрит телевизор.</p>
<p>
Томас смотрит телевизор.
</p>
Аналогично идентичными должны быть и следующие два примера:
<a>my favorite website</a>
<a>
my favorite website
</a>
36. Спецификация не HTML-данных
Текст скрипта и стилевые данные могут появиться в содержимом элемента или в качестве значения атрибута.
Замечание. DTD определяет данные скриптов и стилей как Cdata для содержимого элементов и значения атрибутов. Правила SGML не позволяют использование символьных объектов в Cdata элементах, но допускают их в Cdata значений атрибутов. Разработчикам следует обращать особое внимание на случаи обмена данными скриптов и стилей методом вырезания и вставления между элементами и значениями атрибутов.
Эта асимметрия означает также, что при кросскодировании (transcoding) из богатого кодового набора символов в более бедный, кодировщик не может просто заменить неконвертируемые символы в скрипте или стилевых данных соответствующим цифровыми кодами. Он должен произвести разборку (анализ) HTML-документа и узнать все о каждом скрипте и стилевом языке для того, чтобы правильно обработать соответствующие данные.
Содержимое элемента
Когда скрипт или стилевые данные являются содержимым элемента (script и style), данные начинаются немедленно после начальной метки элемента и кончаются на первом etago ("</") разграничителе, за которым следует имя символа ([a-za-z]), это может быть и не конечной меткой элемента.
Разработчики должны избегать использования строк "</" в теле элемента.
Нелегальный пример:
Следующий текст скрипта содержит недопустимую последовательность "</" (в качестве части "</em>") перед конечной меткой script:
<script type="text/javascript">
document.write ("<em>this won't work</em>")
</script>
В javascript, этот код может быть представлен корректно, путем сокрытия разграничителя Etago перед начальным символом имени SGML:
<script type="text/javascript">
document.write ("<em>this will work<\/em>")
</script>
В tcl, можно выполнить это следующим образом:
<script type="text/tcl">
document write "<em>this will work<\/em>"
</script>
В vbscript эта проблема может быть обойдена с помощью функции chr():
"<em>this will work<" & chr(47) & "em>"
Значения атрибутов
Когда скриптовые или стилевые данные представляют собой значение атрибута, разработчики должны избегать случаев использования одиночных или двойных кавычек в значениях атрибута в соответствии с рекомендациями языка скрипта или описания стиля. Разработчики должны также избегать включения "&", если "&" не означает начало символьного объекта.
* '"' should be written as """ or """
* '&' should be written as "&" or "&"
Таким образом, например, можно написать:
<input name="num" value="0"
onchange="if (compare(this.value, "help")) {gethelp()}">
37. Особенности sgml с ограниченной поддержкой
Системы SGML, соответствующие ISO-8879, должны поддерживать определенное число возможностей, которые не слишком широко поддерживаются агентами пользователя HTML. Разработчикам рекомендуется не использовать все эти возможности.
38. Булевы атрибуты
Разработчики должны учитывать, что многие агенты пользователя распознают не все булевы атрибуты. Например, разработчик может захотеть специфицировать:
<option selected>
вместо
<option selected="selected">
39. Помеченные секции
Помеченные секции играют роль, схожую с конструкцией #ifdef препроцессоров языка c.
<![include[
<!-- это будет включено -->
]]>
<![ignore[
<!-- это будет проигнорировано -->
]]>
SGML определяет также использование помеченных секций для содержимого Cdata, в пределах которого "<" не рассматривается как начало метки, напр.,
<![cdata[
<an> example of <sgml> markup that is
not <painful> to write with < and such.
]]>
Указание на то, что агент пользователя не распознал помеченную секцию, является появление символьной последовательности "]]>", которая будет отображена, когда агент пользователя ошибочно использует первый символ ">" в качестве конечной метки, начинающейся с "<![".
Инструкции обработки
Инструкции обработки представляют собой механизм выявления платформо зависимых идиом. Команды обработки начинаются с последовательности символов <? и завершаются >.
<?instruction >
Например:
<?>
<?style tt = font courier>
<?page break>
<?experiment> ... <?/experiment>
Разработчики должны учитывать то, что многие агенты пользователя отображают (render) инструкции обработки как часть текста документа.
Сжатая форма разметки документа (markup)
Некоторые конструкции SGML shorttag сокращают объем данных, вводимых с клавиатуры. Хотя эти конструкции технически не вводят неопределенности, они уменьшают ясность документов, особенно когда язык усовершенствуется и добавляются новые элементы. Документы, которые используют их, являются SGML документами, но могут не работать со многими существующими средствами HTML.
Конструкции shorttag, о которых идет речь, выглядят следующим образом:
* net tags:
<name/.../
* closed start tag:
<name1<name2>
* empty start tag:
<>
* empty end tag:
</>
40. Заметки по индексному поиску
40.1. Определение языка документа
В глобальном контексте WWW важно знать, какой язык использован при написании документа. Если вы подготовили перевод документа на другие языки, вам следует воспользоваться для ссылки на них элементом Link. Это позволяет индексной поисковой системе предложить пользователям результат на языке, который они предпочитают, вне зависимости от того, как составлен запрос. Например, следующие связи предлагают французскую и немецкую альтернативу поисковой системы.
<link rel="alternate"
type="text/html"
href="mydoc-fr.html" hreflang="fr"
lang="fr" title="la vie souterraine">
<link rel="alternate"
type="text/html"
href="mydoc-de.html" hreflang="de"
lang="de" title="das leben im untergrund">
Обеспечение ключевыми словами и описаниями
Некоторые системы индексации ищут META-элементы, которые определяют список ключевых слов или фраз, разделенных запятыми, или которые дают краткие описания. Поисковая система может представить эти ключевые слова в качестве результата поиска. Значение атрибута имени, которое ищется атрибутом поиска, не определено спецификацией. Рассмотрим такие примеры,
<meta name="keywords" content="vacation, greece, sunshine">
<meta name="description" content="idyllic european vacations">
Выделение начала коллекции
Собрание документов, где ищутся слова, часто преобразуется в собрание HTML-документов. Для результатов поиска полезно указать начало такого собрания. Вы можете помочь системе поиска. Использовав элемент Link с rel="start" и атрибутом title attribute, как в:
<link rel="begin"
type="text/html"
href="page1.html"
title="general theory of relativity">
Роботы с инструкцией индексирования
Люди могут удивиться, узнав, что их сайт был индексирован роботом, хотя роботу не было разрешено посещать некоторые критические секции. Многие web-роботы предлагают возможности администраторам сайтов и провайдерам информации ограничить возможности роботов. Это достигается с помощью двух механизмов: файла "robots.txt" и элемента meta в HTML-документах, как это показано ниже.
41. Поисковые роботы
Файл robots.txt
Когда робот посещает сайт, скажем http://www.foobar.com/, он сначала проверяет наличие http://www.foobar.com/robots.txt. Если он нашел этот документ, он анализирует его содержимое и выясняет, разрешен ли допуск к документу. Вы можете указать, что файл robots.txt доступен только для специальных роботов, и запретить доступ к определенным каталогам и файлам. Ниже приведен пример файла robots.txt, который препятствует всем роботам посещение всего сайта.
user-agent: * # applies to all robots
disallow: / # disallow indexing of all pages
Робот просто будет искать "/robots.txt" uri на вашем сайте, где сайт определен как HTTP-сервер, работающий на определенной ЭВМ с заданным номером порта. Ниже приведены примеры места положения robots.txt:
| Сайт URI | URI для robots.txt |
| http://www.w3.org/ | http://www.w3.org/robots.txt |
| http://www.w3.org:80/ | http://www.w3.org:80/robots.txt |
| http://www.w3.org:1234/ | http://www.w3.org:1234/robots.txt |
| http://w3.org/ | http://w3.org/robots.txt |
Должен быть только один файл "/robots.txt" на сайт. В частности, не следует помещать файл "robots.txt" в пользовательские каталоги, так как робот туда не заглядывает. Если вы хотите, чтобы пользователи создали свои собственные "robots.txt", вы должны их объединить в один общий файл "/robots.txt". Если вы не хотите это делать, пользователи могут вместо этого использовать robots meta tag.
Некоторые советы: URI чувствительны к набору строчными или прописными буквами, а строка "/robots.txt" должна быть набрана строчными буквами.
Пустые строки не допустимы.
Должен быть только одно поле "user-agent" на рекорд. Робот должен либерально интерпретировать это поле. Если значение равно "*", рекорд описывает политику доступа любого робота по умолчанию (робот не соответствует ни одному другому рекорду). Не допускается более одного такого рекорда в файле "/robots.txt".
Поле "disallow" специфицирует URI, который не должен посещаться. Это может быть полный проход, частичный проход, любой URI, который начинается с этой величины, не будет доступен. Например,
disallow: /help запрещает как /help.html так и /help/index.html, в то время как
disallow: /help/ запрещает посещение /help/index.html, но позволяет /help.html.
Пустое значение для "disallow", указывает, что все uri доступны. Хотя бы одно поле "disallow" должно присутствовать в файле robots.txt.
41.1. Роботы и элементы meta
Элемент meta позволяет HTML разработчикам сообщить приходящим роботам, можно ли индексировать документы. В ниже приведенном примере робот не должен ни индексировать документ, ни анализировать его связи.
<meta name="robots" content="noindex, nofollow">
Список терминов в содержимом включает в себя all, index, nofollow, noindex. Имена и содержимое значений атрибутов не зависит от регистра, использованного при наборе текста.
Замечание. В начале 1997 только несколько роботов следовало этим правилам, но ожидается, что ситуация изменится в ближайшее время.
42. Замечания о таблицах
Модель таблиц HTML взята из исследований существующих моделей таблиц SGML. Модель выбрана из соображений простоты и возможностей дальнейшего расширения функций, если это потребуется.
Важно, что модель таблиц HTML согласуется с большинством существующих средств их создания (напр., с текстовыми редакторами).
43. Динамическое реформатирование
Главным соображением при выработке модели таблиц HTML является то, что разработчик не должен заботиться о вариации размера таблиц пользователем или о его выборе шрифтов.
Это делает рискованным задание ширины колонки в абсолютных единицах (пикселях). Вместо этого таблицы должны быть способны динамически приспосабливать размер таблицы к размерам имеющегося окна и к выбранным шрифтам. Разработчик может сформулировать пожелания относительно ширин колонок, но агент пользователя может и не следовать этим пожеланиям. Он должен обеспечить размер ячейки, достаточный для размещения самого крупного элемента.
44. Инкрементное отображение
Для больших таблиц или для медленных сетевых соединений пользователю важна возможность реализации инкрементного отображения таблицы. Агенты пользователя должны быть способны начать отображение таблицы до того, как будут получены все данные. Ширина окна по умолчанию для большинства агентов пользователя равна 80 символам, а графика для многих HTML страниц сконструирована с учетом этого значения. При специфицировании числа колонок, включая различные механизмы управления шириной колонок, разработчики могут подсказать агенту пользователя как организовать инкрементное отображение таблицы.
Для инкрементного отображения броузер должен знать число колонок и их ширину. Ширина таблицы по умолчанию определяется размером текущего окна (ширина="100%"). Это значение может быть изменено путем установки атрибута width в элементе table. По умолчанию, все колонки имеют равные ширины, но вы можете специфицировать ширины колонок с помощью одного или нескольких элементов col.
Последний пункт – число колонок. Некоторые люди предлагают ждать, пока первый ряд таблицы будет получен, но это может занять много времени, если ячейки содержат много материала. Имеет смысл, особенно для целей инкрементного отображения таблиц, задать разработчикам число колонок в таблице явно (в элементе table).
Разработчикам нужен способ, сообщить агенту пользователя, следует ли использовать инкрементное отображение или изменить размер таблицы с тем, чтобы можно было разместить содержимое ячеек. В режиме двухпроходного определения размеров число колонок определяется при первом проходе.
При инкрементном режиме сначала должно быть объявлено число колонок (с помощью элементов col или colgroup).
45. Структура и презентация
HTML различает структурную разметку, такую как параграфы и цитаты из идиом отображения (rendering idioms) таких как поля, шрифты, цвета, и т.д. Как это различие влияет на таблицы? С чисто теоретической точки зрения выравнивание текста внутри ячеек таблицы и определение границы между ячейками, проблема отображения, а не структуры. На практике полезно использовать обе возможности. Модель таблиц HTML оставляет большую часть управления отображением стилевым листам.
Современные издательские системы предоставляют очень богатые возможности управления отображением таблиц. Эти спецификации предлагают разработчику возможность выбора класса стиля границ. Атрибут frame управляет наличием разграничительных линий вокруг таблицы, в то время как атрибут rules определяет выбор разделительных линий внутри таблицы. Стилевой атрибут может быть использован для спецификации информации, управляющей процессом отображения для индивидуальных элементов. Дополнительная информация может быть получена через элемент style в заголовке документа или из подключенного стилевого листа.
46. Группы строк и колонок
Таблицы рассматриваются как соединение опционной надписи и последовательность рядов, которые в свою очередь состоят из последовательности ячеек. Модель еще более дифференцирует заголовок и информационные ячейки и позволяет ячейкам занимать несколько рядов и колонок.
Эта спецификация (модель таблиц cals) позволяет группировать ряды в секции заголовка, тела и основания. Она упрощает представление информации и может использоваться для повторения верхней и нижней секций при разбиении таблиц на несколько страниц, или для обеспечения фиксированного заголовка над панелью со скролированием текста. Это позволяет отображать нижнюю секцию, не дожидаясь пока вся таблица будет обработана.
47. Доступность
Модель таблиц HTML включает атрибуты для пометки каждой ячейки с целью высококачественного преобразования текста в голос.
Те же самые атрибуты могут использоваться для поддержки автоматического обмена с базами данных и электронными таблицами.
48. Рекомендуемые алгоритмы верстки
Если присутствуют элементы col или colgroup, они специфицируют число колонок и таблица может быть отображена с использованием фиксированной раскладки. В противном случае будет применен автоматический алгоритм раскладки, описанный ниже.
Если атрибут width не специфицирован, визуальные агенты пользователя должны предполагать значение по умолчанию, равное 100%.
Рекомендуется, чтобы агенты пользователя увеличивали ширину таблицы за пределы, специфицированные width в случаях, когда содержимое может не поместиться. Агенты пользователя, которые корректируют значение, заданное width должны делать это в пределах разумного. Агенты пользователя могут выбрать переносы строк, когда горизонтальный скролинг не желателен или не практичен.
Для целей раскладки агенты пользователя должны учитывать, что табличные надписи (специфицированные элементом caption) ведут себя подобно ячейкам таблицы. Каждая надпись является ячейкой, которая простирается через все колонки таблицы, если она размещена вверху или внизу таблицы, или через все ряды, если она находится справа или слева от таблицы.
49. Фиксированные алгоритмы верстки
Для этого алгоритма предполагается, что число колонок известно. Ширины колонок по умолчанию делаются равными. Разработчики могут поменять эти установки, задав относительные или абсолютные значения колонок с помощью элементов colgroup или col. Значение ширины по умолчанию равно расстоянию от левого до правого поля, но оно может быть скорректировано с помощью атрибута width в элементе table, или определено из абсолютных ширин колонок. Для того чтобы работать со смесью абсолютных и относительных ширин, сначала нужно выделить место для колонок с заданной абсолютной шириной. После этого, оставшееся пространство делится между колонками с учетом их относительных ширин.
Сам по себе синтаксис таблицы не гарантирует взаимосогласованности значений атрибутов.
Например, число элементов col и colgroup может не совпадать с числом колонок, используемых в таблице. Дополнительные проблемы возникают, когда колонки слишком узки и может произойти переполнение ячейки. Ширина таблицы, как это специфицировано элементами table или col может вызвать переполнение ячейки таблицы. Рекомендуется, чтобы агенты пользователя умели выходить из этого положения, например, путем переноса слов.
В случае, когда переполнение ячейки вызывается словом, которое не может быть поделено, агент пользователя может рассмотреть возможность изменения ширин колонок и повторного отображения таблицы. В худшем случае, можно допустить обрубание слов, если вариации ширин колонок и скроллинг оказались невозможными. В любом случае, если содержимое ячейки разделено или обрублено, об этом должно быть сообщено пользователю соответствующим способом.
50. Алгоритм авто выкладки
Если число колонок не специфицировано элементами col и colgroup, тогда агент пользователя должен использовать алгоритм автоматической выкладки. Он использует два прохода по данным таблицы и линейно масштабирует размеры таблицы.
При первом проходе запрещается разрыв строк и агент пользователя отслеживает минимальные и максимальные ширины для всех ячеек. Максимальная ширина задается самой длинной строкой. Так как разрыв строк запрещен, параграфы рассматриваются, как длинные строки, если не введены переносы строк с помощью элементов BR. Минимальная ширина задается наиболее широким текстовым элементом (словом, изображением, и т.д.) с учетом абзацев маркеров и пр. Другими словами необходимо определить минимальную ширину ячейки, которая необходима в пределах окна для того, чтобы ячейка не переполнилась. Допуская перенос слов, мы минимизируем необходимость горизонтального скролинга или обрубания содержимого ячейки.
Этот процесс применим к любым вложенным таблицам. Минимальные и максимальные ширины ячеек для вложенных таблиц используются для определения минимальной и максимальной ширины этих таблиц, и, следовательно, таблиц их прародителей.
Алгоритм является линейным и не зависит от глубины вложения.
Минимальная и максимальная ширины ячейки используются для определения минимальной и максимальной ширины колонки. Эти значения в свою очередь служат для нахождения минимальной и максимальной ширины таблицы. Следует учитывать, что ячейки могут содержать вложенные таблицы, но это не усложняет программу сколько-нибудь значительно. Следующим шагом является определение ширин колонок в соответствии с доступным пространством (напр., зазором между левым и правым полями).
Внешние ограничители таблицы и внутренние разделительные линии должны учитываться при определении ширин колонок. Имеется три варианта:
Минимальная ширина таблицы равна или шире наличного пространства. В этом случае следует приписать минимальную ширину и разрешить агенту пользователя горизонтальный скролинг.
Максимальная ширина таблицы укладывается в имеющееся пространство. В этом случае следует установить ширины колонок по максимуму.
Максимальная ширина таблицы больше наличного пространства, а минимальная - меньше.
Если ширина таблицы задана атрибутом width, агент пользователя пытается установить соответствующим образом ширины колонок.
Если с помощью элемента col указаны относительные длины колонок, алгоритм может быть модифицирован так, что ширина колонок может превысить минимально объявленное значение для того, чтобы удовлетворить требования относительных ограничений. Элементы col должны рассматриваться только как рекомендации и ширины колонок не должны делаться меньше их минимальной ширины. Аналогично, колонки не должны делаться настолько широкими, что таблица не поместится в отведенное ей окно. Если элемент col специфицирует относительную ширину нуль, ширина колонки должна быть выбрана равной минимальной ширине.
Если несколько ячеек в различных рядах одной и той же колонки используют выравнивание, тогда по умолчанию все такие ячейки должны быть выстроены в линию, вне зависимости от того, какой символ был использован для выравнивания.
Выбор имен атрибутов.
Предпочтительно выбрать значения для атрибута frame, согласующееся с атрибутом rules и параметрами выравнивания. Например: none, top, bottom, topbot, left, right, leftright, all. К сожалению, sgml требует нумеровать значения атрибутов, чтобы обеспечить их уникальность для каждого элемента, вне зависимости от имени атрибута. Это сразу создает проблемы для "none", "left", "right" и "all". Значения для атрибута frame были выбраны для исключения конфликтов с атрибутами rules, align, и valign.
51. Замечания о формах
Инкрементное отображение
Инкрементное отображение документов, полученных по сети, создают некоторые проблемы, связанные с формами. Агенты пользователя должны позаботиться о том, чтобы форма не была передана серверу до тех пор, пока не получены все элементы формы.
Если формы связаны со скриптами стороны клиента, создаются предпосылки для будущих проблем. Например, хандлер скриптов для данного поля может относиться к полю, которого пока не существует.
52. Будущие проекты
Данная спецификация определяет набор элементов и атрибутов, достаточно мощных, чтобы выполнить основные требования по генерации форм. Однако остается пространство для дальнейшего совершенствования. Например, следующие проблемы могут найти решение в будущем:
Диапазон типов полей формы слишком ограничен по сравнению с современными пользовательскими интерфейсами. Например, не существует возможности использования табуляции при вводе данных.
Серверы не могут корректировать поля в уже записанных формах, и вынуждены вместо этого передавать весь HTML-документ.
Другим возможным расширением может стать атрибут usemap элемента input для использования в качестве карты изображения на стороне клиента, когда "type=image". Элемент area, соответствующий позиции, где была нажата кнопка мыши, должен будет выдать информацию, передаваемую серверу. Чтобы избежать необходимости модифицировать скрипты сервера, может оказаться разумным расширить возможности area в отношении передачи значений координат x и y для использования их элементом input.
53. Заметки о скриптах
Эта спецификация резервирует синтаксис для будущей поддержки скриптовых макро в атрибутах cdata HTML. Целью этого является допущение установки атрибутов, зависящих от свойств объектов, которые были записаны выше на странице. Синтаксис выглядит следующим образом:
attribute = "... &{ macro body }; ... "
Существующая практика скриптов
Тело макро состоит из одного или более записей на языке скриптов. Точка с запятой, следующая за правой фигурной скобкой, всегда необходима, иначе правая фигурная скобка будет рассматриваться как часть текста макро.
Обработка Cdata атрибутов производится следующим образом:
Анализатор текста sgml вычисляет любой символьный объект SGML (напр., ">").
Далее скриптовые макросы обрабатываются интерпретатором скриптов.
И, наконец, результирующая последовательность символов передается приложению для последующей обработки.
Обработка макро имеет место, когда документ загружается, но эта процедура не повторяется, когда документ изменяется в размере или перезакрашивается.
Не рекомендуемый пример:
Ниже приведены примеры с использованием Javascript. Первый делает фон документа рэндомизованным:
<body bgcolor='&{randomrbg};'>
Возможно, вы хотите приглушить фон для просмотра в вечернее время:
<body bgcolor='&{if(date.gethours > 18)...};'>
Следующий пример использует javascript при установке координат для карты изображения на стороне клиента:
<map name=foo>
<area shape="rect" coords="&{myrect(imageuri)};" href="&{myuri};" alt="">
</map>
Этот пример устанавливает размер изображения, базируясь на свойствах документа:
<img src="bar.gif" width='&{document.banner.width/2};' height='50%' alt="banner">
Вы можете установить URI для связи или изображения с помощью скрипта:
<SCRIPT type="text/javascript">
function manufacturer(widget) {
...
}
function location(manufacturer) {
...
}
function logo(manufacturer) {
...
}
</SCRIPT>
<A href='&{location(manufacturer("widget"))};'>widget</A>
<IMG src='&{logo(manufacturer("widget"))};' alt="logo">
Последний пример показывает, как SGML CDATA атрибуты могут помещаться в одинарные или двойные кавычки. Если вы помещаете строку атрибута в одиночные кавычки, вы можете использовать двойные кавычки в качестве части строки атрибута. Другой подход связан с использованием " для двухкавычечных меток:
<IMG src="&{logo(manufacturer("widget"))};" alt="logo">
53.1. Зарезервированный синтаксис для будущих скриптов
Так как не существует гарантии того, что имя адресата рамки уникально, представляется разумным описать существующую практику нахождения имени адресата, заданного в рамке:
Если имя адресата является зарезервированным именем, как это записано в нормативном тексте, следует использовать его так, как описано.
В противном случае, следует выполнить поиск согласно иерархии рамок в окне, где содержится эта связь. Следует использовать первую рамку, имя которой соответствует искомому.
Если такой рамки не найдено на этапе (2), используется этап 2 для каждого окна в послойном порядке, начиная с переднего плана. Поиск прекращается, когда найдена рамка с соответствующим именем.
Если такой рамки не найдено на этапе (3), следует создать новое окно и присвоить ему имя адресата.
54. Замечания о доступности
Замечание. Следующий алгоритм генерации альтернативного текста может быть заменен рекомендациями W3C Web Accessibility Initiative Group. Для получения дополнительной информации предлагается ссылка [WAIGUIDE].
Когда разработчик не устанавливает атрибут alt для элементов IMG или APPLET, агент пользователя должен предоставить альтернативный текст, который получается следующим способом:
Если title был специфицирован, его значение должно использоваться в качестве альтернативного текста. В противном случае, если HTTP-заголовки предоставляют информацию о title, эта информация и должна использоваться в качестве альтернативного текста. В противном случае, если включенные объекты содержат текстовые поля (напр., GIF изображения содержат некоторые текстовые поля), информация из текстовых полей извлекается и используется в качестве альтернативного текста.
Так как агенты пользователя для извлечения текстовых данных могут быть вынуждены заполучить сначала весь объект, пользовательские агенты могут воспользоваться каким-либо более экономным подходом. В противном случае, в отсутствии другой информации агенты пользователя должны воспользоваться именем файла (за вычетом расширения) в качестве альтернативного текста.
Если разработчик не установил атрибут alt для элемента INPUT, агент пользователя должен получить альтернативный текст следующим образом:
Если был специфицирован атрибут title, его значение должно использоваться в качестве альтернативного текста. В противном случае, если специфицировано имя, его значение используется как альтернативный текст. В противном случае (кнопки submit и reset), значение атрибута type должно использоваться в качестве альтернативного текста.
55. Замечания о безопасности
Якоря, встроенные изображения и все другие элементы, которые содержат URI в качестве параметров, могут вызвать повторное обращение к URI в ответ на ввод пользователя. В этом случае, следует рассмотреть соображения безопасности RFC-1738. Широко распространенные методы посылки запросов форм – HTTP и SMTP – обеспечивают ограниченную конфиденциальность. Провайдеры информации, которые запрашивают необходимые данные с помощью форм – точнее с помощью элементов INPUT, type="password" – должны позаботиться о том, чтобы сами пользователи учитывали возможность утечки конфиденциальной информации.
55.1. Соображения безопасности для форм
Агент пользователя не должен посылать какой-либо файл, который пользователь не указал явно, как подлежащий пересылке. Таким образом, агенты пользователя HTML должны требовать подтверждения для любых имен файлов по умолчанию, которые могут быть указаны значениями атрибутов элемента INPUT.
Эта спецификация не содержит механизма шифрования данных. Раз файл загружен, агент должен обработать и записать его соответствующим образом.
56. Ссылки на литературу и сервера
| [CSS1] | "Cascading Style Sheets, level 1", H. W. Lie and B. Bos, 17 December 1996. Доступно по адресу: http://www.w3.org/TR/REC-CSS1-961217 |
| [DATETIME] | "Date and Time Formats", W3C Note, M. Wolf and C. Wicksteed, 15 September 1997. Доступно по адресу: http://www.w3.org/TR/NOTE-datetime |
| [IANA] | "Assigned Numbers", STD 2, RFC 1700, USC/ISI, J. Reynolds and J. Postel, October 1994. Доступно по адресу: http://ds.internic.net/rfc/rfc1700.txt |
| [ISO639] | "Codes for the representation of names of languages", ISO 639:1988. Дополнительная информация может быть получена по адресу: http://www.iso.ch/cate/d4766.html. См. также http://www.sil.org/sgml/iso639a.html |
| [ISO3166] | "Codes for the representation of names of countries", ISO 3166:1993. |
| [ISO8601] | "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:1988 |
| [ISO8879] | "Information Processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML)", ISO 8879:1986. Информация о стандарте может быть получена по адресу http://www.iso.ch/cate/d16387.html . |
| [ISO10646] | "Information Technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane", ISO/IEC 10646-1:1993. Данная спецификация учитывает также первые пять поправок к документу ISO/IEC 10646-1:1993 |
| [ISO88591] | "Information Processing -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1", ISO 8859-1:1987 |
| [MIMETYPES] | Список зарегистрированных типов содержимого (типы MIME). Список зарегистрированных типов можно найти по адресу ftp://ftp.isi.edu/in-notes/iana/assignments/media-types /. |
| [RFC1555] | "Hebrew Character Encoding for Internet Messages", H. Nussbacher and Y. Bourvine, December 1993. Доступно по адресу: http://ds.internic.net/rfc/rfc1555.txt . |
| [RFC1556] | "Handling of Bi-directional Texts in MIME", H. Nussbacher, December 1993. Доступно по адресу: http://ds.internic.net/rfc/rfc1556.txt |
| [RFC1738] | "Uniform Resource Locators", T. Berners-Lee, L. Masinter, and M. McCahill, December 1994. Доступно по адресу: http://ds.internic.net/rfc/rfc1738.txt. |
| [RFC1766] | "Tags for the Identification of Languages", H. Alvestrand, March 1995. Доступно по адресу: http://ds.internic.net/rfc/rfc1766.txt |
| [RFC1808] | "Relative Uniform Resource Locators", R. Fielding, June 1995. Доступно по адресу: http://ds.internic.net/rfc/rfc1808.txt . |
| [RFC2044] | "UTF-8, a transformation format of Unicode and ISO 10646", F. Yergeau, October 1996. Доступно по адресу: http://ds.internic.net/rfc/rfc2044.txt |
| [RFC2045] | "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", N. Freed and N. Borenstein, November 1996. Доступно по адресу: http://ds.internic.net/rfc/rfc2045.txt. Учтите, что это RFC замещает RFC1521, RFC1522 и RFC1590. |
| [RFC2046] | "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", N. Freed and N. Borenstein, November 1996. Доступно по адресу: http://ds.internic.net/rfc/rfc2046.txt. Учтите, что это RFC замещает RFC1521, RFC1522 и RFC1590. |
| [RFC2068] | "HTTP Version 1.1 ", R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, and T. Berners-Lee, January 1997. Доступно по адресу: http://ds.internic.net/rfc/rfc2068.txt |
| [RFC2119] | "Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. Доступно по адресу: http://ds.internic.net/rfc/rfc2119.txt |
| [RFC2141] | "URN Syntax", R. Moats, May 1997. Доступно по адресу: http://ds.internic.net/rfc/rfc2141.txt |
| [SRGB] | "A Standard Default color Space for the Internet", version 1.10, M. Stokes, M. Anderson, S. Chandrasekar, and R. Motta, 5 November 1996. Доступно по адресу: http://www.w3.org/Graphics/Color/sRGB |
| [UNICODE] | "The Unicode Standard: Version 2.0", The Unicode Consortium, Addison-Wesley Developers Press, 1996. Спецификация учитывает также обнаруженные ошибки http://www.unicode.org/unicode/uni2errata/bidi.htm. Для получения дополнительной информации, рекомендуется посмотреть базовую страницу Unicode Consortium's по адресу http://www.unicode.org |
| [URI] | "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", T. Berners-Lee, R. Fielding, L. Masinter, 18 November 1997. Доступно по адресу: http://www.ics.uci.edu/pub/ietf/uri/draft-fielding-uri-syntax-01.txt. Работа продолжается и ожидается, что тексты RFC-1738 и RFC-1808 будут пересмотрены. |
| [WEBSGML] | "Proposed TC for WebSGML Adaptations for SGML", C. F. Goldfarb, ed., 14 June 1997. Доступно по адресу: http://www.sgmlsource.com/8879rev/n1929.htm |
Информационные ссылки
| [BRYAN88] | "SGML: An Author' s Guide to the Standard Generalized Markup Language", M. Bryan, Addison-Wesley Publishing Co., 1988 |
| [CALS] | Continuous Acquisition and Life-Cycle Support (CALS). CALS является стратегией Министерства обороны США для достижения эффективного создания, обмена и использования цифровых данных для оборудования и систем оружия. Дополнительная информация доступна на базовой странице CALS по адресу http://navysgml.dt.navy.mil/cals.html |
| [CHARSETS] | Registered charset values. Загрузка списка зарегистрированных наборов символов возможна по адресу ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets |
| [CSS2] | "Cascading Style Sheets, level 2", B. Bos, H. W. Lie, C. Lilley, and I. Jacobs, November 1997. Доступно по адресу: http://www.w3.org/TR/WD-CSS2 |
| [DCORE] | The Dublin Core: дополнительная информация доступна по адресу http://purl.org/metadata/dublin_core |
| [ETHNO] | "Ethnologue, Languages of the World", 12th Edition, Barbara F. Grimes editor, Summer Institute of Linguistics, October 1992. |
| [GOLD90] | "The SGML Handbook", C. F. Goldfarb, Clarendon Press, 1991. |
| [HTML30] | "HyperText Markup Language Specification Version 3.0", Dave Raggett, September 1995. Доступно по адресу: http://www.w3.org/MarkUp/html3/CoverPage |
| [HTML32] | "HTML 3.2 Reference Specification", Dave Raggett, 14 January 1997. Доступно по адресу: http://www.w3.org/TR/REC-html32 |
| [HTML3STYLE] | "HTML and Style Sheets", B. Bos, D. Raggett, and H. Lie, 24 March 1997. Доступно по адресу: http://www.w3.org/TR/WD-style |
| [LEXHTML] | "A Lexical Analyzer for HTML and Basic SGML", D. Connolly, 15 June 1996. Доступно по адресу: http://www.w3.org/TR/WD-html-lex |
| [PICS] | Platform for Internet Content (PICS). Дополнительная информация доступна по адресу http://www.w3.org/PICS |
| [RDF] | The Resource Description Language: дополнительная информация доступна по адресу http://www.w3.org/Metadata/RDF |
| [RFC822] | "Standard for the Format of ARPA Internet Text Messages", Revised by David H. Crocker, August 1982. Доступно по адресу: http://ds.internic.net/rfc/rfc822.txt . |
| [RFC850] | "Standard for Interchange of USENET Messages", M. Horton, June 1983. Доступно по адресу: http://ds.internic.net/rfc/rfc850.txt |
| [RFC1468] | "Japanese Character Encoding for Internet Messages", J. Murai, M. Crispin, and E. van der Poel, June 1993. Доступно по адресу: http://ds.internic.net/rfc/rfc1468.txt |
| [RFC1630] | "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", T. Berners-Lee, June 1994. Доступно по адресу: http://ds.internic.net/rfc/rfc1630.txt |
| [RFC1866] | "HyperText Markup Language 2.0", T. Berners-Lee and D. Connolly, November 1995. Доступно по адресу: http://ds.internic.net/rfc/rfc1866.txt |
| [RFC1867] | "Form-based File Upload in HTML", E. Nebel and L. Masinter, November 1995. Доступно по адресу: http://ds.internic.net/rfc/rfc1867.txt. Ожидается, что RFC1867 будет поправлено, см.: ftp://ftp.ietf.org/internet-drafts/draft-masinter-form-data-01.txt, в настоящее время ведутся работы |
| [RFC1942] | "HTML Tables", Dave Raggett, May 1996. Доступно по адресу: http://ds.internic.net/rfc/rfc1942.txt |
| [RFC2048] | "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", N. Freed, J. Klensin, and J. Postel, November 1996. Доступно по адресу: http://ds.internic.net/rfc/rfc2048.txt. Учтите, что это RFC замещает RFC-1521, RFC-1522 и RFC-1590. |
| [RFC2070] | "Internationalization of the HyperText Markup Language", F. Yergeau, G. Nicol, G. Adams, and M. Dьrst, January 1997. Доступно по адресу: http://ds.internic.net/rfc/rfc2070.txt |
| [SGMLOPEN] | SGML Consortium. Базовая страница консорциума находится по адресу http://www.sgmlopen.org |
| [SP] | SP представляет собой общедоступный интерпретатор SGML. Доступно по адресу: ftp://ftp.jclark.com/pub/sp /. Дополнительная информация доступна по адресу: http://www.jclark.com |
| [SQ91] | "The SGML Primer", 3rd Edition, SoftQuad Inc., 1991 |
| [TAKADA] | "Multilingual Information Exchange through the World-Wide Web", Toshihiro Takada, Computer Networks and ISDN Systems, Vol. 27, No. 2, pp. 235-241, November 1994. |
| [WAIGUIDE] | Базовая информация по формированию HTML документов доступна на сайте Web Accessibility Initiative (WAI): http://www.w3.org/WAI/. |
| [VANH90] | "Practical SGML", E. van Herwijnen, Kluwer Academic Publishers Group, Norwell and Dordrecht, 1990 |
может быть представлена в виде:
Таблица может быть представлена в виде:
| 1 | 2 | 3 |
| 4 | 6 | |
| 7 | 8 | 9 |
Версия HTML 4.0 включает в себя механизмы контроля горизонтального и вертикального выравнивания, стилями границ таблицы и полями ячеек.
14.12. Горизонтальное и вертикальное выравнивание
<!entity % cellhalign “align (left|center|right|justify|char) #implied
char cdata #implied -- выравнивание по символу, напр. char=”:” --
charoff cdata #implied -- смещение выравнивания по символу -- >
<!entity % cellvalign “valign (top|middle|bottom|baseline) #implied” >
Определения атрибутов
align = left|center|right|justify|char
Этот атрибут определяет способ выравнивания текста в ячейке. Возможны следующие значения:
| left: | выравнивание по левому краю (значение атрибута по умолчанию) |
| center: | Выравнивание текста в ячейке по центру (значение по умолчанию для заголовков) |
| right: | выравнивание текста по правому краю ячейки. |
| justify: | выравнивание текста по правой и левой границам. |
| char: | выравнивание текста по некоторому символу. |
valign = top|middle|bottom|baseline
Этот атрибут определяет вертикальное позиционирование текста в ячейке таблицы. Возможны следующие значения:
| top: | текст прижимается к верхней границе ячейки. |
| middle: | текст размещается по центру ячейки (значение по молчанию для заголовков) |
| bottom: | текст прижимается к нижней границе ячейки. |
| baseline: | все ячейки в ряду должны быть выровнены по высоте так, чтобы их первые строки были на одной высоте. Это не касается последующих строк. |
char = cdata
Этот атрибут определяет символ в тексте, который будет выполнять роль оси для выравнивания. Значением по умолчанию является точка для английского языка и запятая - для французского (бывает полезно для колонок цифр с долями целого).
charoff = length
Если этот атрибут присутствует, он определяет смещение текста относительно символа выравнивания (рассматривается первый такой символ). Если в строке такого символа нет, то она должна быть сдвинута горизонтально в конец относительно позиции выравнивания.
Рассмотрим пример таблицы с выравниванием по символу точка.
<table border=”border”>
<colgroup>
<col><col align=”char” char=”.”>
<thead>
<tr><th>Vegetable <th>Cost per kilo
<tbody>
<tr> <td> lettuce <td>$1
<tr> <td> silver carrots <td>$10.50
<tr> <td>golden turnips <tr>$100.30
</table>
Отформатированная таблица будет выглядеть как:
| vegetable | cost per kilo |
| lettuce | $1 |
| silver carrots | $10.50 |
| golden turnips | $100.30 |
14.13. Границы и линии
Следующие атрибуты влияют на рамки таблицы и внутренние линии.
frame = void|above|below|hsides|lhs|rhs|vsides|box|border
Эти атрибуты определяют, какая из сторон рамки, окружающей таблицу, будет видимой.
| void: | Ни одна из сторон. Значение по умолчанию. |
| above: | Только верхняя сторона. |
| below: | Только нижняя сторона. |
| hsides: | Только нижняя и верхняя стороны. |
| vsides: | Только правая и левая стороны. |
| lhs: | Только левая сторона. |
| rhs: | Только правая сторона. |
| box: | Все четыре стороны. |
| border: | Все четыре стороны. |
rules = none|groups|rows|cols|all
Этот атрибут определяет, какие линии появится между ячейками в пределах таблицы. Возможные значения:
| none: | Никаких линий, значение по умолчанию. |
| groups: | Линии имеются только между группами рядов и столбцов. |
| rows: | Линии имеются только между рядами. |
| cols: | Линии имеются только между столбцами. |
| all: | Линии имеются между рядами и столбцами. |
border = cdata
Эти атрибуты определяют ширину рамки вокруг таблицы в пикселях. В приведенном ниже примере таблица имеет рамку в 5 пикселей и присутствует с правой и левой сторон таблицы. Разделительные линии имеются между всеми колонками.
<table border=”5” frame=vsides” rules=”cols”>
<tr> <td>1 <td>2 <td>3
<tr> <td>4 <td>5 <td>6
<tr> <td>7 <td>8 <td>9
</table>
Следующие установки должны выполняться агентом пользователя для совместимости.
Установка border=”0” подразумевает frame=”void” и, если не специфицировано иного, rules=”none”. Другие установки border подразумевают frame=”border” и, если не оговорено иное, rules=”all”. Значение “border” в стартовой метке элемента table должно интерпретироваться как значение атрибута frame. Это предполагает, что rules=”all” и ненулевое значение атрибута border. Так, например:
<frame border=”2”> у <frame border=”2” frame=”border” rules=”all”>
и
<frame border> <=< frame frame=”border” rules=”all”>
14.14 Поля ячейки
Два атрибута регулируют зазор между и внутри ячеек.
cellspacing = length
Этот атрибут определяет то, какое расстояние должно быть оставлено между рамкой таблицы и начальным или конечным краем ячейки для каждого ряда или колонки, а также между ячейками в таблице.
cellpadding = length
Этот атрибут определяет расстояние между границей ячейки и его содержимым.
Во всех последующих таблицах атрибут cellspacing определяет, что ячейки разделяются друг от друга и от рамки таблицы расстоянием в 20 пикселей. Атрибут cellpadding определяет, что верхняя и нижняя граница ячейки отстоит от его содержимого на 10% доступного пространства по вертикали (всего 20%). Аналогично поля ячейки в горизонтальном направлении составляют 10% от горизонтального размера ячейки.
<table>
<tr cellpadding=”20”> <tr>data1 <td cellpadding=”20%”>data2 <td>data3
</table>
Ниже приведены примеры, где проиллюстрировано взаимодействие различных элементов. Пример 1.
<table border=”border”>
<caption>A test table with merged cells </caption>
| <tr> | <th> rowspan=2><th colspan=”2”>average |
| <th rowspan=”2”>other<br>category<th>misc | |
| <tr> | <th>height<th>weight |
| <tr> | <th>align=”left”>males<td>1.9<td>0.003 |
| <tr> | <th> align=”left” rowspan=”2”>females<td>1.7<td>0.002 |
/table>
сдвинута к левому краю
Таблица сдвинута к левому краю документа.
center: Таблица размещена по центральной оси документа.
right: Таблица сдвинута к правому краю документа.
width = length
Этот атрибут определяет желательную ширину всей таблицы для агента пользователя. В отсутствии этого атрибута размер таблицы определяется агентом пользователя.
cols = integer
Этот атрибут задает число колонок в таблице. Если он задан, агент пользователя разворачивает таблицу по мере получения данных.
14.2. Вычисление числа рядов и колонок в таблице
Число рядов в таблице равно числу tr-элементов в ее содержимом. Агенты пользователя должны игнорировать ряды с номерами за пределами этого числа. Существует несколько путей определения числа колонок.
Сканирование рядов таблицы и определение максимального числа колонок. Если число колонок в таблице превосходит число ячеек, ряд дополняется пустыми ячейками.
Подсчитывается число колонок, как это специфицировано элементами COL и colgroup.
Используется атрибут COLS элемента table
Агент пользователя может предположить, что число колонок в примере, приведенном ниже равно трем.
<table cols= “3”>
… текст таблицы …
</table>
Если число колонок в таблице не задано атрибутом COLS, то визуальный агент пользователя будет ждать прихода всей информации о таблице, прежде чем приступит к ее отображению. Таким образом, атрибут cols позволяет отображать таблицу ряд за рядом по мере поступления данных.
14.3. Ориентация таблиц
Ориентация таблиц определяется атрибутом dir элемента table. Для таблиц, ориентированных слева направо (ориентация по умолчанию), первая колонка расположена слева, а первый ряд сверху. Возможна ориентация таблицы справа налево. Для того чтобы специфицировать таблицу с нумерацией колонок справа налево нужно установить значение атрибута dir.
<table dir=”rtl”>
… содержимое таблицы …
</table>
14.4. Надписи и таблица. Элемент caption
<!element caption - - (%inline;) +>
<!entity % calign “(top|bottom|left|right)”>
| <!attlist caption | -- Надпись для таблицы -- | |
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| align %CAlign; #implied | -- относительно таблицы -- > |
Определение атрибута
align = top|bottom|left|right
Этот атрибут определяет положение подписи по отношению к таблице. Возможные значения:
top: подпись над таблицей. Это значение по умолчанию.
bottom: подпись под таблицей.
left: подпись слева от таблицы.
right: подпись справа от таблицы.
Надпись, если она присутствует, должна описывать природу таблицы. Элемент caption должен располагаться непосредственно после начальной метки table. Например:
<table cols=”3”>
<caption>cups of coffee consumed by each senator</caption>
… остальная часть таблицы …
</table>
14.5. Группы рядов. Элементы thead, tfoot и tbody
<!element thead – o (tr+)>
<!element tfoot - o (tr+)>
<!element tbody o o (tr+) >
| <!attlist (thead|tfoot|tbody)-- секция таблицы -- | ||
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| %CEllhalign; | -- горизонтальное выравнивание в ячейке -- | |
| %CEllvalign; | -- вертикальное выравнивание в ячейке -- > |
в приведенном ниже примере
Таблица в приведенном ниже примере имеет две группы колонок. Первая группа содержит 10 колонок, а вторая – 5 колонок. Значение ширины колонки по умолчанию для каждой из колонок в первой группе равно 50 пикселей. Для второй группы ширина колонки определяется минимально возможным значением.
<table>
<colgroup span=”10” width=”50”>
<colgroup span=”5” width=”0*”>
<thead>
<tr> ….
</thead>
14.8. Элемент col
<!element col - o empty>
| <!attlist col | -- группы колонок и свойства -- | |
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| span number 1 | -- число колонок в группе -- | |
| width cdata #implied | -- спецификация ширин колонок -- | |
| %CEllhalign; | -- горизонтальное выравнивание в ячейках -- | |
| %CEllvalign; | -- вертикальное выравнивание в ячейках -- > |
Определение атрибута
width = length
Этот атрибут задает значение по умолчанию для ширины колонок в группе. Атрибут может также принимать значение “0*” (смотри выше) и “i*”, где i - целое. Это называется относительной шириной. Когда агент пользователя выделяет место для таблицы, он сначала определяет габариты, а уже затем делит выделенное пространство, определяя относительные ширины рядов и колонок. Число i при этом определяет относительную долю, выделяемую данной колонке. Значение “*” эквивалентно “1*”.
Каждая группа колонок может содержать нуль или более элементов col. Элемент col не определяет группу колонок в том смысле, как это делает colgroup, он предоставляет способ задать значения атрибутов для всех колонок группы. Атрибут span элемента col имеет следующее значение.
В отсутствии декларации span каждый элемент col представляет одну колонку. Если атрибут span имеет значение n>0, текущий элемент col действует на n колонок таблицы. Если атрибут span равен нулю, текущий элемент col имеет воздействие на все оставшиеся колонки таблицы, начиная с текущей. Что же касается colgroup, атрибут width для col воздействует на ширины колонок, к которым относится этот элемент.
Если элемент cal действует на несколько колонок, тогда его атрибут width специфицирует ширину каждой колонки в его зоне ответственности.
Ниже приведен пример таблицы, имеющей две группы колонок. Первая группа содержит три колонки, вторая – две колонки. Доступное место по горизонтали определяется следующим образом. Сначала агент пользователя выделяет 30 пикселей для первой колонки. Затем будет выделено минимально возможное место для второй колонки. Оставшееся место по горизонтали будет поделено на 6 равных частей. Колонка 3 получит 2 такие порции, колонка 4 – одну, а колонка 5 получит 3.
<table>
<colgroup>
| <col width=”30”> | |
| <col width=”0*”> | |
| <col width=”2*”> |
<colgroup align=”center”>
| <col width=”1*”> | |
| <col width=”3*” align=”char” char=”:”> |
<thead>
<tr> …..
</table>
Мы установили значение атрибута align во второй группе колонок равным “center”. Все ячейки в каждой колонке этой группы наследуют это значение. Но оно может быть изменено. В действительности последний элемент col делает это, специфицируя то, что все колонки, которыми он управляет, будут выровнены по символу “:”.
14.9. Ряды таблицы. Элемент tr
<!element tr - o (th|td)+>
| <!attlist tr | -- ряд таблицы -- | |
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| %CEllhalign; | -- горизонтальное выравнивание в ячейках -- | |
| %CEllvalign; | -- вертикальное выравнивание в ячейках -- | |
| bgcolor %color #implied | -- цвет фона в ряду -- > |
Элементы TR действуют как контейнеры рядов ячеек таблицы. Ниже приведен пример таблицы, которая имеет три ряда, каждый из которых открывается элементом TR.
<table>
<caption>cups of coffee consumed by each senator</caption>
<tr> … Ряд заголовка …
<tr> … Первый ряд данных …
<tr> … Второй ряд данных …
… остальная часть таблицы …
</table>
14.10. Ячейки таблицы. Элементы th и td
<!element (th|td) - o %block>
| <!attlist (th|td) | -- Заголовок или данные ячейки -- | |
| %attrs; | -- %coreattrs, %i18n, %events -- | |
| axis cdata #iplied | -- содержимое ячейки по умолчанию -- | |
| axes cdata #iplied | -- список имен axis -- | |
| nowrap (nowrap) #implied | -- блокирует разрыв слов -- | |
| bgcolor %color #implied | -- цвет фона ячейки -- | |
| rowspan number | -- число рядов, охватываемых ячейкой -- | |
| colspan number | -- число колонок, охватываемых ячейкой -- | |
| %CEllhalign; | -- горизонтальное выравнивание в ячейках -- | |
| %CEllvalign; | -- вертикальное выравнивание в ячейках -- > |
Определения атрибутов
axis = cdata
Атрибут определяет сокращенное имя заголовка ячейки. Имя ячейки по умолчанию – ее содержимое.
axes = cdata-list
Значение этого атрибута представляет собой список имен axis, разделенных запятыми. Эти имена представляют собой заголовки рядов и колонок, принадлежащих данной ячейке. В отсутствии этого атрибута агент пользователя идентифицирует эти имена сам.
rowspan = integer
Этот атрибут специфицирует число рядов в текущей ячейке. Значение этого атрибута по умолчанию равно 1. Значение нуль означает, что ячейка включает в себя все ряды, начиная с текущего, до конца таблицы.
colspan = integer
Этот атрибут специфицирует число колонок в текущей ячейке. Значение этого атрибута по умолчанию равно 1. Значение нуль означает, что ячейка включает в себя все колонки, начиная с текущей, до конца таблицы.
nowrap
Использование не рекомендуется. В случае присутствия этот булев атрибут указывает агенту пользователя заблокировать автоматический разрыв слов при выкладке их в ячейку. Вместо этого атрибута рекомендуется использовать стилевой лист.
Элемент TH запоминает заголовок, в то время как TD – данные. Это позволяет агенту пользователя обрабатывать заголовки и данные по-разному даже в отсутствии стилевого листа. Ячейки могут быть пустыми (не содержать данных). Ниже приведен пример таблицы с четырьмя колонками, имеющими заголовки.
<table>
<caption>Cups of coffee consumed by each senator</caption>
<tr> <th>name <th>Cups <th> Type of coffee <th> Suger?
<tr> <td>T. Sexton <td>10 <td>espresso <td>no
<tr> <td>J. Dinnen <td>5 <td>decaf <td>yes
… остальная часть таблицы …
</table>
Агент пользователя представит верхнюю часть данной таблицы в виде:
Cups of coffee consumed by each senator
| Name | Cups | Type of coffee | Sugar |
| T. Sexton | 10 | espresso | no |
| J. Dinnen | 5 | decaf | yes |
Для того чтобы сделать таблицу более выразительной, можно ввести атрибут border в элемент table.
<table border=”border”>
… остальная часть таблицы …
</table>
Тогда агент пользователя отобразит начало данной таблицы следующим образом:
Cups of coffee consumed by each senator
| Name | Cups | Type of coffee | Sugar |
| T. Sexton | 10 | espresso | no |
| J. Dinnen | 5 | decaf | yes |
Ячейки с этикетками
Атрибуты axis и exes предоставляют возможность снабжать ячейки таблицы этикетками (labels). Синтезаторы речи могут использовать эти этикетки для идентификации содержимого и положения каждой ячейки. Программное обеспечение может рассматривать эти этикетки как имена полей базы данных при занесении содержимого таблицы в банк данных. Ниже представлен пример таблицы, где значение атрибута axis представляет собой фамилию сенатора.
<table border=”border”>
<caption>Caps of coffee consumed by each senator</caption>
<tr> <th>Name <th>Cups <th> Type of coffee <th> suger?
<tr> <td axis=”sexton” exes=”name”>T. Sexton <td>10
<td>espresso <td>no
<tr> <td axis=”dinnen” exes=”name”>J. Dinnen <td>5 <td>decaf <td>yes
</table>
14.11. Ячейки, которые занимают несколько рядов или колонок
Ячейки могут охватывать несколько рядов или колонок. Число рядов или колонок в ячейке определяется атрибутами rowspan и colspan для соответственно TH или TD-элементов. В таблице, которая была описана, ячейка в ряду 4 вторая колонка должна занимать три колонки, включая текущий ряд.
<table border=”border”>
<caption>Caps of coffee consumed by each senator</caption>
<tr> <th>Name <th>Cups <th> Type of coffee <th> suger?
<tr> <td>T. Sexton <td>10 <td>espresso <td>no
<tr> <td>J. dinnen <td>5 <td>decaf <td>yes
<tr> <td>A. Soria <td colspan=”3”<em>not available</em>
</table>
Эта таблица будет развернута визуальным агентом пользователя как:
Caps of coffee consumed by each senator
| Name | Cups | Type of coffee | Suger? |
| T. Sexton | 10 | espresso | no |
| J. Dinnen | 5 | decaf | yes |
| A. Soria | not available |
Этот пример иллюстрирует как описания ячеек, которые распространяются более чем на один ряд или колонку, влияет на определение последующих ячеек. Рассмотрим следующее описание таблицы.
<table border=”border”>
<tr> <td>1 <td rowspan=”2”>2 <td>3
<tr> <td>4 <td>6
<tr> <td>7 <td>8 <td>9
</table>
Transformation applied (применено преобразование)
14 Transformation applied (применено преобразование)
Должно добавляться промежуточным кэшем или прокси, если он использует какое-либо преобразование, изменяющее кодировку содержимого (как это специфицировано в заголовке Content-Encoding) или тип среды (как это описано в заголовке Content-Type) отклика, если только этот код предупреждения не присутствует уже в отклике.
UA – агент пользователя
Рисунок 4.5.6.1.3. UA – агент пользователя
На рисунке показаны три промежуточные ступени (A, B, и C) между агентом пользователя (UA) и базовым сервером (O). Запрос или отклик, двигаясь по этой цепочке, должен пройти четыре различных соединительных сегмента. Это обстоятельство крайне важно, так как некоторые опции HTTP применимы только для ближайших соединений. Хотя схема линейна, на практике узлы могут участвовать в большом числе других взаимодействий. Например, B может получать запросы от большого числа клиентов помимо A, и переадресовывать запросы к другим серверам кроме C.
Любой участник обмена, который не используется в качестве туннеля, может воспользоваться кэшем для запоминания запросов. Буфер может сократить длину цепочки в том случае, если у одного из участников процесса имеется в буфере отклик для конкретного запроса, что может, кроме прочего, заметно снизить требования к пропускной способности канала. Не все запросы могут записываться в кэш, некоторые из них могут содержать модификаторы работы с кэшем.
В действительности имеется широкое разнообразие архитектур и конфигураций буферных запоминающих устройств и прокси, разрабатываемых в настоящее время или уже доступных через World Wide Web. Эти системы включают иерархии прокси-серверов национального масштаба, задачей которых является сокращение трансокеанского трафика, системы, которые обслуживают широковещательные и мультикастинговые обмены, организации, распространяющие фрагменты информации с CD-ROM, занесенной в кэши и т. д.. HTTP-системы, используются в корпоративных сетях Интранет с большими пропускными способностями и перемежающимися соединениями. Целью HTTP/1.1 является поддержка широкого разнообразия уже существующих систем и расширение возможностей будущих приложений в отношении надежности и адаптируемости.
Коммуникации HTTP обычно реализуются через соединения TCP/IP. Порт по умолчанию имеет номер 80, но и другие номера портов вполне допустимы. Это не исключает использования HTTP поверх любого другого протокола в Интернет, или других сетей.
HTTP предполагает надежное соединение; применим любой протокол, который может гарантировать корректную доставку сообщений.
В HTTP/1.0, большинство приложений используют новое соединение для каждого обмена запрос/отклик. В HTTP/1.1, соединение может быть использовано для одного или более обменов запрос/отклик, хотя соединение может быть разорвано по самым разным причинам.
4.5.6.1.1. Соглашения по нотации и общая грамматика
1.1. Расширенные BNF
Все механизмы, специфицированные в данном документе, описаны с использованием обычного текста и расширенных форм Бахуса-Наура BNF (Backus-Naur Form; см. RFC 822). Пользователи должны быть знакомы с этой нотацией для понимания данной спецификации. Расширение BNF включает в себя следующие конструкции:
name = definition
Имя правила не требует помещения в угловые скобки. Некоторые базовые правила записываются прописными буквами, например, SP, LWS, HT, CRLF, DIGIT, ALPHA и пр.
"literal"
Двойные кавычки используются для выделения символьного текста.
rule1 | rule2
Элементы, разделенные вертикальной чертой, ("|") являются альтернативными, например, "yes | no" допускает yes или no (да или нет).
(rule1 rule2)
Элементы, помещенные в круглые скобки, рассматриваются как один элемент. Так, "(elem (foo | bar) elem)" допускают последовательности "elem foo elem" и "elem bar elem".
*rule
Символ "*", предшествующий элементу, указывает на повторение. Полная форма "*element" указывает как минимум на и как максимум повторений элемента. Значения по умолчанию равны 0 и бесконечности, так что "*( элемент)" позволяет любое число, включая ноль; "1*element" требует по меньшей мере один; а "1*2element" допускает один или два.
[rule]
В квадратные скобки заключаются опционные элементы; "[foo bar]" эквивалентно "*1(foo bar)".
N rule
Специальный повтор: "(элемент)" эквивалентно "*(элемент)"; то есть, точно (element).
Таким образом, 2DIGIT является 2-значным числом, а 3ALPHA представляет собой строку из трех буквенных символов.
#rule
Конструкция "#" определена подобно "*", для описания списка элементов. Полная форма имеет вид "#element ", отмечая, по меньшей мере и по большей элементов, отделенных друг от друга одной или более запятыми (",") и опционно строчным пробелом (LWS – Linear White Space). Это делает обычную форму списков очень простой. Запись "( *LWS элемент *( *LWS "," *LWS элемент)) " может быть представлена как "1#element". Всюду, где используется эта конструкция, допускаются нулевые элементы, но они не учитываются при подсчете элементов. То есть, допускается запись "(элемент), (элемент) ", но число элементов при этом считается равным двум. Следовательно, там, где необходим хотя бы один элемент, должен присутствовать, по крайней мере, один ненулевой элемент. Значениями по умолчанию являются 0 и бесконечность, таким образом "#элемент" позволяет любое число, включая нуль; "1#элемент" требует, по меньшей мере один, а "1#2элемент" допускает один или два.
; комментарий
Точка с запятой, смещенная вправо от линейки текста, открывает комментарий, который продолжается до конца строки. Это простой способ включения замечаний в текст спецификаций.
implied *LWS
Грамматика, описанная в данной спецификации, ориентирована на слова. Если не оговорено обратное, строчный пробел (LWS) может быть заключен между любыми двумя соседними словами (лексема или заключенная в кавычки строка), и между смежными лексемами (token) и разделителями (TSpecials) без изменения интерпретации поля. По крайней мере один разграничитель (TSpecials) должен присутствовать между любыми двумя лексемами, так как они иначе будут интерпретироваться как одна.
1.2. Основные правила
Следующие правила используются практически во всей спецификации для описания основных конструкций разбора (парсинга).
| OCTET | = |
| CHAR | = |
| UPALPHA | = |
| LOALPHA | = < любая строчная буква US-ASCII "a".."z"> |
| ALPHA | = UPALPHA | LOALPHA (строчная или прописная буква) |
| DIGIT | = |
| CTL | = |
| CR | = |
| LF | = |
| SP | = |
| HT | = |
| = |
/p> HTTP/1. 1 определяет последовательность CR LF, как маркер конца для всех протокольных элементов, за исключением тела элемента. Маркер конца строки в пределах тела объекта определен соответствующим типом среды.
| CRLF | = CR LF |
| LWS | = [CRLF] 1*( SP | HT ) |
| TEXT | = |
| HEX | = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT |
| Token | = 1* |
| Tspecials | = "(" | ")" | "" | "@" |
| | "," | ";" | ":" | "\" | | |
| | "/" | "[" | "]" | "?" | "=" | |
| | "{" | "}" | SP | HT |
| Комментарий | = "(" *( ctext | комментарий) ")" |
| ctext | = |
| quoted-string | = ( *(qdtext) ) |
| qdtext | = > |
| quoted-pair | = "\" CHAR |
2.1. Версия HTTP
HTTP использует схему нумерации "." для отображения версии протокола. Политика присвоения версии протоколу ориентирована на то, чтобы позволить отправителю указать формат сообщения и его емкость. Номер версии не меняется при добавлении компонент сообщения, которые не влияют на характер обмена.
Число увеличивается, когда в протокол внесены изменения, которые не изменили общий алгоритм разбора сообщений, но которые изменили семантику сообщений и добавили новые возможности отправителю. Число увеличивается в случае, когда изменен формат протокольного сообщения.
Версия HTTP-сообщения указывается в поле HTTP-Version в первой строке сообщения.
| HTTP | Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT |
Приложения, посылающие запросы или отклики, так как это определено в спецификации, должны включать HTTP-Version "HTTP/1.1". Использование этого номера версии указывает, что посылающее приложение совместимо с этой спецификацией.
Версия HTTP приложения является верхней, совместимость с которой гарантируется. Приложения прокси-серверов и сетевых портов должны проявлять осторожность при переадресации сообщений с протокольной версией, отличной от поддерживаемой ими. Так как версия протокола указывает на возможности отправителя, прокси никогда не должны пересылать сообщения с версией больше, чем их собственная; если получено сообщение более высокой версии, прокси/порт должен либо понизить версию запроса, либо послать отклик об ошибке или переключиться в режим туннеля.
Запросы с версией ниже, чем у прокси/ порта могут быть повышены при переадресации, при этом major часть версии сервера и запроса должны совпадать.
Замечание: Преобразование между версиями может включать модификацию полей заголовка.
2.2. Универсальные идентификаторы ресурсов (URI)
URI известен под многими именами: WWW адрес, универсальный идентификатор документа (Universal Document Identifiers), универсальный идентификатор ресурса (Universal Resource Identifiers), и, наконец, универсальный локатор ресурса URL (Uniform Resource Locators; тождество URI и URL сомнительно, так как URL является частным случаем URI (примечание переводчика)) и универсальное имя ресурса (URN). Что касается HTTP, универсальный идентификатор ресурса представляет собой форматированную строку символов, которая идентифицирует имя, положение или какие-то еще характеристики ресурса.
2.2.1. Общий синтаксис
URI в HTTP может быть представлен в абсолютной или относительной форме по отношению к некоторому известному базовому URI, в зависимости от контекста его использования. Эти две формы отличаются тем, что абсолютный URI всегда начинается с имени схемы, за которым следует двоеточие (например HTTP: или FTP:).
| URI | = ( absoluteURI | relativeURI ) [ "#" фрагмент ] |
| AbsoluteURI | = схема ":" *( uchar | reserved ) |
| RelativeURI | = net_path | abs_path | rel_path |
| net_path | = "//" net_loc [ abs_path ] |
| abs_path | = "/" rel_path |
| rel_path | = [ проход ] [ ";" params ] [ "?" query ] |
| path | = fsegment *( "/" сегмент ) |
| fsegment | = 1*pchar |
| segment | = *pchar |
| params | = param *( ";" param ) |
| param | = *( pchar | "/" ) |
| scheme | = 1*( ALPHA | DIGIT | "+" | "-" | "." ) |
| net_loc | = *( pchar | ";" | "?" ) |
| query | = *( uchar | reserved ) |
| fragment | = *( uchar | reserved ) |
| pchar | = uchar | ":" | "@" | "&" | "=" | "+" |
| uchar | = unreserved | escape |
| unreserved | = ALPHA | DIGIT | safe | extra | national |
| escape | = "%" HEX HEX |
| reserved | = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
| extra | = "!" | "*" | "'" | "(" | ")" | "," |
| safe | = "$" | "-" | "_" | "." |
| unsafe | = CTL | SP | | "#" | "%" | "" |
| national | = |
/p> Более детальную информацию о синтаксисе и семантике URL можно найти в RFC-1738 [4] и RFC-1808 [11]. Приведенные выше BNF включают в себя национальные символы, недопустимые в URL, так как это специфицировано в RFC 1738, так как серверам HTTP не запрещено использование любых наборов символов, допустимых в rel_path частях адресов, HTTP-прокси могут получить запросы URI, не определенные в рамках RFC-1738.
Протокол HTTP не устанавливает каких-либо ограничений на длину URI. Серверы должны быть способны обрабатывать URI любых ресурсов, имеющих любую длину. Сервер должен выдать отклик 414 (Request-URI Too Long – URI запроса слишком длинен), если URI длиннее, чем может обработать сервер (см. раздел 9.4.15).
Замечание: Серверы должны избегать использования URI длиннее 255 байт, так как некоторые старые клиенты или прокси-приложения не могут корректно работать с такими длинами.
2.2.2. HTTP URL
Схема "HTTP" используется для локализации сетевых ресурсов с помощью протокола HTTP. Далее определены синтаксис и семантика HTTP URL, зависящие от схемы.
| http_URL | = "http:" "//" host [ ":" port ] [ abs_path ] |
| host | = |
| port | = *DIGIT |
2.2.3. Сравнение URI
При сравнении двух URI с целью проверки их идентичности, клиент должен использовать по октетное сравнение с учетом регистра, в котором напечатаны символы. Допускаются следующие исключения:
Номер порта не указан, тогда для данного URI берется значение по умолчанию;
Сравнение имен ЭВМ и схем не должно быть чувствительным к строчным/прописным буквам;
Пустой abs_path эквивалентен abs_path "/".
Символы, отличные от типов "reserved" и "unsafe" устанавливаются равными их эквивалентам в кодировке ""%" HEX HEX".
Например, следующие три URI являются эквивалентными:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7Esmith/home.html
3.3. Форматы даты/времени
3.3.1. Полная дата
HTTP приложения допускают три различных формата для представления метки времени и даты:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC-822, актуализировано в RFC-1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC-850, объявлено устаревшим в RFC-1036
Sun Nov 6 08:49:37 1994 ; ANSI C's ASCtime() format
Первый формат предпочтительнее, как стандарт Интернет и представляет собой форму фиксированной длины, определенную RFC-1123. Второй формат используется достаточно широко, но базируется на устаревшем документе RFC-850 [12], формат даты не имеет 4 цифр года. Клиенты и серверы HTTP/1.1, которые анализируют дату, должны уметь работать со всеми тремя форматами (для совместимости с HTTP/1.0), хотя они должны сами генерировать время/дату согласно формату RFC-1123.
Замечание: Получатели значений даты должны быть готовы принять коды, которые посланы не приложениями HTTP, что случается, когда данные поступают через прокси/порты или по почте в SMTP- или NNTP-форматах.
Все марки времени/даты HTTP должны соответствовать времени по Гринвичу (GMT). Это указано в первых двух форматах путем включения строки "GMT" и должно предполагаться во всех прочих случаях.
| HTTP-date | = RFC-1123-date | rRFC-850-date | asctime-date | |
| RFC-1123-date | = wkday "," SP date1 SP time SP "GMT" | |
| RFC-850-date | = weekday "," SP date2 SP time SP "GMT" | |
| asctime-date | = wkday SP date3 SP time SP 4DIGIT | |
| date1 | = 2DIGIT SP month SP 4DIGIT | ; day month year (e.g., 02 Jun 1982) |
| date2 | = 2DIGIT "-" month "-" 2DIGIT | ; day-month-year (e.g., 02-Jun-82) |
| date3 | = month SP ( 2DIGIT | ( SP 1DIGIT )) | ; month day (e.g., Jun 2) |
| time | = 2DIGIT ":" 2DIGIT ":" 2DIGIT | ; 00:00:00 - 23:59:59 |
| wkday | = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun" | |
| weekday | = "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday" | "Saturday" | "Sunday" | |
| month | = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec" |
/p> Замечание: HTTP требования для формата метки даты/времени применимы только для использования в рамках реализации самого протокола. Клиенты и сервера не требуют применения этих форматов для пользовательских презентаций, протоколирования запросов и т.д..
2.3.2. Интервалы времени в секундах
Некоторые поля заголовка HTTP допускают спецификацию значения времени в виде целого числа секунд, представленного в десятичной форме и равного времени с момента получения сообщения.
delta-seconds = 1*DIGIT
2.4. Наборы символов
HTTP использует то же определение термина "набор символов", что дано для MIME:
Термин "набор символов", используемый в данном документе, относится к методу, который с помощью одной или более таблиц преобразует последовательность октетов в последовательность символов. Заметьте, что не требуется безусловное обратное преобразование, при этом не все символы могут быть доступны и одному и тому же символу может соответствовать более чем одна последовательность октетов. Это определение имеет целью допустить различные виды кодировок символов, от простых однотабличных, таких как US-ASCII, до сложных - таблично переключаемых методов, используемых, например, в ISO 2022. Однако, определение, связанное с набором символов MIME, должно полностью специфицировать схему соответствия октетов и символов. Использование внешних профайлов для определения схемы шифрования не допустимо.
Замечание. Здесь "набор символов" ближе к понятию "кодирование символов". Однако так как HTTP и MIME используют один и тот же регистр, важно, чтобы терминология также была идентичной.
Наборы символов HTTP идентифицируются лексемами, которые не чувствительны к использованию строчных или прописных букв. Полный набор лексем определен регистром наборов символов IANA [19].
charset = token
Несмотря на то, что HTTP позволяет использовать произвольную лексему в качестве значения charset, любая лексема, значение которой определено в рамках регистра набора символов IANA, должна представлять символьный набор, определенный этим регистром.
Приложение должно ограничить использование символьных наборов только теми, которые определены регистром IANA.
2.5. Кодировки содержимого
Значения кодировки содержимого указывают на кодовое преобразование, которое было или может быть выполнено над объектом. Кодировки содержимого первоначально применены для того, чтобы иметь возможность архивировать документ или преобразовать его каким-то другим способом без потери идентичности или информации. Часто объект запоминается закодированным, передается и только получателем декодируется.
content-coding = token
Все значения кодировок содержимого не зависят от того, используются строчные или прописные символы. HTTP/1.1 использует значения кодировок содержимого в полях заголовка Accept-Encoding (раздел 13.3) и Content-Encoding (раздел 13.12). Хотя значение описывает кодирование содержимого, более важным является то, что оно определяет механизм декодирования.
Комитет по стандартным числам Интернет IANA (Internet Assigned Numbers Authority) выполняет функции регистра для значений лексем кодирования содержимого, этот регистр хранит следующие лексемы:
gzip
Формат кодирования, реализуемый программой архивации файлов "gzip" (GNU zip), как описано в RFC 1952 [25]. Этот формат соответствует кодированию Lempel-Ziv (LZ77) с 32 битным CRC.
compress
Формат кодирования, реализуемый стандартной программой UNIX для архивации файлов "compress". Этот формат соответствует адаптивному методу кодирования Lempel-Ziv-Welch (LZW).
Замечание: Использование имен программ для идентификации форматов кодирования не является желательным и будет в будущем заменено. Их использование здесь является следствием исторической практики. Для совместимости с предшествующими реализациями HTTP, приложения должны считать "x-gzip" и "x-compress" эквивалентными "gzip" и "compress" соответственно.
deflate
Формат "zlib" определен документом RFC 1950 [31] в комбинации с механизмом сжатия "deflate", описанным в RFC 1951 [29].
Новые значения лексем кодирования содержимого должны регистрироваться. Для обеспечения взаимодействия между клиентами и серверами спецификации алгоритмов кодирования содержимого должны быть общедоступны.
2.6. Транспортное кодирование
Значения транспортного кодирования используются для определения кодового преобразования, которому был подвергнут или желательно подвергнуть объект для того, чтобы гарантировать безопасную его транспортировку через сеть. Этот вид преобразования отличен от кодирования содержимого, так как относится к сообщению, а не исходному объекту.
| Transfer-coding | = "chunked" | transfer-extension |
| Transfer-extension | = token |
Транспортные кодировки аналогичны используемым значениям Content-Transfer-Encoding MIME, которые были введены для обеспечения безопасной передачи двоичных данных через 7-битную транспортную среду. Однако безопасная транспортировка имеет другие аспекты в рамках 8-битного протокола передачи сообщений. В HTTP, единственной небезопасной характеристикой тела сообщения является неопределенность его длины (раздел 6.2.2), или желание зашифровать данные при передаче по общему каналу.
Блочное кодирование фрагментов модифицирует тело сообщения для того, чтобы передать его в виде последовательности пакетов, каждый со своим индикатором размера, за которым следует опционная завершающая запись (footer), содержащая поля заголовка объекта. Это позволяет передать динамически сформированное содержимое, снабдив его необходимой информацией для получателя, который, в конце концов, сможет восстановить все сообщение.
| Chunked | Body = *chunk "0" CRLF footer CRLF |
| Chunk | = chunk-size [ chunk-ext ] CRLF chunk-data CRLF |
| Hex-no-zero | = |
| Chunk-size | = hex-no-zero *HEX |
| Chunk-ext | = *( ";" chunk-ext-name [ "=" chunk-ext-value ] ) |
| Chunk-ext-name | = token |
| Chunk-ext-val | = token | quoted-string |
| Chunk-data | = chunk-size(OCTET) |
| footer | = *entity-header |
/p> Блочное кодирование фрагментов завершается пакетом нулевой длины, за которыми следует завершающая запись и пустая строка. Назначение завершающей записи заключается в том, чтобы дать информацию о динамически сформированном объекте; приложения не должны пересылать поля заголовка в завершающей записи, кроме тех, которые специально оговорены, например, такие как Content-MD5 или будущие расширения HTTP для цифровой подписи. Пример процесса такого кодирования представлен в приложении 16.4.6.
Все приложения HTTP/1.1 должны быть способны получать и декодировать получаемые фрагменты ("chunked"-кодирование), и должны игнорировать расширения транспортного кодирования, которые они не понимают. Сервер, получающий тело объекта с транспортной кодировкой, которую он не понимает, должен отослать отклик c кодом 501 (Unimplemented – не применимо), и закрыть соединение. Сервер не должен использовать транспортное кодирование при посылке данных клиенту HTTP/1.0.
2.7. Типы среды
HTTP использует типы среды Интернет (Internet Media Types) в полях заголовка Content-Type (раздел 13.18) и Accept (раздел 13.1) для того, чтобы обеспечить широкий и открытый обмен с самыми разными типа среды.
| Media-type | = type "/" subtype *( ";" parameter ) |
| type | = token |
| subtype | = token |
| Parameter | = attribute "=" value | |
| attribute | = token | |
| value | = token | quoted-string |
Замечание. Некоторые старые приложения HTTP не узнают параметры типа среды. При посылке данных старому HTTP-приложению, программы должны использовать параметры типа среды, только когда они необходимы по описанию типа/субтипа. Значения типа среды регистрируются IANA (Internet Assigned Number Authority). Процесс регистрации типа среды описан в RFC 2048 [17]. Использование незарегистрированных типов среды настоятельно не рекомендуется.
2.7.1. Канонизация и текст по умолчанию
Типы среды Интернет регистрируются каноническим образом. Вообще, тело объекта, передаваемого с помощью HTTP сообщений, должно быть представлено соответствующим каноническим способом, прежде чем будет послано, исключение составляет тип "text", как это описано в следующем параграфе.
В случае канонической формы субтип среды "text" использует CRLF для завершения строки текста. HTTP ослабляет это требование и позволяет передавать текст, используя просто CR или LF, представляющие разрыв строки. HTTP приложения должны воспринимать CRLF, “голое” CR и LF как завершение строки для текстовой среды полученной через HTTP. Кроме того, если текст представлен в символьном наборе, где нет октетов 13 и 10 для CR и LF соответственно, как это имеет место в случае мультибайтных символьных наборов, HTTP позволяет использовать соответствующие символьные представления для CR и LF. Эта гибкость в отношении разрыва строк относится только к текстовой среде в теле объекта; CR или LF не должны подставляться вместо CRLF в любые управляющие структуры HTTP (такие как поля заголовка).
Если тело объекта закодировано с помощью Content-Encoding, исходные данные, прежде чем подвергнуться кодированию должны были иметь форму, указанную выше.
Параметр "charset" используется с некоторыми типами среды, чтобы определить символьный набор (раздел 2.4). Когда параметр charset не задан отправителем явно, субтип среды "text" определяется так, что используется символьный набор по умолчанию "ISO-8859-1".
Данные с набором символов, отличным от "ISO-8859-1" или его субнабора, должны помечаться соответствующим значением charset.
Некоторые программы HTTP/1.0 интерпретируют заголовок Content-Type без параметра charset, неправильно предполагая, что "получатель должен решить сам, какой это набор". Отправители, желающие заблокировать такое поведение, могут включать параметр charset, даже когда charset равен ISO-8859-1 и должны делать так, когда известно, что это не запутает получателя.
К сожалению, некоторые старые HTTP/1.0 клиенты не обрабатывают корректно параметр charset. HTTP/1.1 получатели должны учитывать метку charset, присланную отправителем, и те агенты пользователя, которые умеют делать предположение относительно символьного набора, должны использовать символьный набор из поля content-type, если они поддерживают этот набор, а не набор, предпочитаемый получателем.
2.7.2. Составные типы
MIME обеспечивает нескольких составных типов – инкапсуляция одного или более объектов в общее тело сообщения. Все составные типы имеют общий синтаксис, как это определено в MIME [7], и должны включать граничный параметр, являющийся частью значения типа среды. Тело сообщения является само протокольным элементом и, следовательно, должно использовать только CRLF для обозначения разрывов строки. В отличии от MIME, завершающая часть любого составного cообщения должна быть пустой. HTTP приложения не должны передавать завершающую часть (даже если исходное составное сообщение содержит такую завершающую часть (эпилог-подпись).
В HTTP, составляющие части тела могут содержать поля заголовка, которые существенны для значения этих частей. Рекомендуется, чтобы поле заголовка Content-Location (раздел 13.15) было включено в часть тела каждого вложенного объекта, который может быть идентифицирован URL.
Вообще, рекомендуется, чтобы агент пользователя HTTP имел идентичное или схожее поведение с агентом пользователя MIME при получении составного типа. Если приложение получает неузнаваемый составной субтип, оно должно обрабатывать его также как "multipart/mixed".
Замечание: Тип "multipart/form-data" специально определен для переноса данных совместимого с методом обработки почтовых запросов, как это описано в RFC 1867 [15].
2.8. Лексемы (token) продукта
Лексемы продукта служат для того, чтобы позволить взаимодействующим приложениям идентифицировать себя с помощью имени и версии программного продукта. Большинство полей, использующих лексемы продукта допускают также включение в список субпродуктов, которые образуют существенную часть приложения, их лексемы отделяются пробелом. По договоренности, продукты перечисляются в порядке их важности для идентификации приложения.
| Product | = token ["/" product-version] |
| Product-version | = token |
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
Лексемы продукта должны быть короткими и, кроме того, использование их для оповещения или передачи маловажной информации абсолютно запрещено. Хотя любой символ лексемы может присутствовать в версии продукта, рекомендуется, чтобы эта лексема использовалась только для идентификации версии (то есть, последовательные версии одного и того же продукта должны отличаться только в части версии продукта).
2.9. Значения качества (Quality values)
HTTP согласование параметров содержимого (раздел 12) использует короткие числа с плавающей запятой для указания относительной важности (веса) различных согласуемых параметров. Вес нормализуется на истинное число в диапазоне 0 - 1, где 0 равен минимальному, а 1 максимальному значению. Приложения HTTP/1.1 не должны генерировать более трех чисел после запятой. Рекомендуется, чтобы конфигурация пользователя для этих значений удовлетворяла тем же ограничениям.
qvalue = ( "0" [ "." 0*3DIGIT ] ) | ( "1" [ "." 0*3("0") ] )
"Quality values" (значения качества) является неверным названием, так как эти значения в большей степени отражают относительную деградацию желательного качества.
2.10. Языковые метки
Языковая метка идентифицирует естественный язык.
Компьютерные языки в этот перечень не входят. HTTP использует языковые метки в полях Accept-Language и Content-Language.
Синтаксис и регистр языковых меток HTTP тот же, что и определенный в RFC 1766 [1]. Языковая метка содержит одну или более частей: первичная языковая метка и последовательность субметок, которая может и отсутствовать:
| language-tag | = primary-tag *( "-" sub-tag ) |
| primary-tag | = 1*8ALPHA |
| sub-tag | = 1*8ALPHA |
en, en-US, en-cockney, i-cherokee, x-pig-latin
где любые две буквы первичной метки представляют собой языковую аббревиатуру ISO 639 и две буквы исходной субметки соответствуют коду страны ISO 3166 (последние три метки не являются зарегистрированными; все кроме последней могут быть зарегистрированы в будущем).
2.11. Метки объектов
Метки объектов служат для сравнения двух или более объектов из одного и того же запрошенного ресурса. HTTP/1.1 использует метки объектов в полях заголовков ETag (раздел 13.20), If-Match (раздел 13.25), If-None-Match (раздел 13.26) и If-Range (раздел 13.27). Метки объекта состоят из строк, заключенных в кавычки, перед ней может размещаться индикатор слабости.
| entity-tag | = [ weak ] opaque-tag |
| Weak | = "W/" |
| opaque-tag | = quoted-string |
"Слабая метка объекта " (weak entity tag) отмечается префиксом "W/", может относиться к двум объектам ресурса, только если объекты эквивалентны и могут быть взаимозаменяемы. Слабая метка объекта может использоваться для "слабого" сравнения.
Метка объекта должна быть уникальной для всех версий всех объектов, сопряженных с конкретным ресурсом. Значение данной метки объекта может использоваться для объектов, полученных в результате запросов для различных URI без использования данных об эквивалентности этих объектов.
2.12. Структурные единицы
HTTP/1. 1 позволяет клиенту запросить только часть объекта (диапазон). HTTP/1.1 использует структурные единицы, определяющие выделение части объекта, в полях заголовка Range (раздел 13.36) и Content-Range (раздел 13.17). Объект может быть разбит на фрагменты с использованием различных структурных единиц.
| range-unit | = bytesunit | other-range-unit |
| bytes-unit | = "bytes" |
| other-range-unit | = token |
4.5.6.1.3. HTTP сообщение
3.1. Типы сообщений
Сообщения HTTP включают в себя запросы клиента к серверу и отклики сервера клиенту.
HTTP-message = Request | Response ; HTTP/1.1 messages
Сообщения запрос (раздел 5) и отклик (раздел 6) используют общий формат сообщений RFC-822 [9] для передачи объектов (поле данных сообщения). Оба типа сообщений состоят из стартовой строки, одного или более полей заголовка (также известные как "заголовки"), пустой строки (то есть, строка, содержащая CRLF), отмечающей конец полей заголовка, а также опционного тела сообщения.
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
В интересах надежности, рекомендуется серверам игнорировать любые пустые строки, полученные, когда ожидается Request-Line (строка запроса). Другими словами, если сервер читает протокольный поток в начале сообщения и получает сначала CRLF, он должен игнорировать CRLF.
Замечание: Определенные не корректные реализации HTTP/1.0 клиентов генерируют дополнительные CRLF после запроса POST. Клиент HTTP/1.1 не должен посылать CRLF до или после запроса.
3.2. Заголовки сообщений
Поля заголовка HTTP, которые включают в себя поля общего заголовка (раздел 3.5), заголовка запроса (раздел 4.3), заголовка отклика (раздел 6.2), и заголовка объекта (раздел 6.1), следуют тому же общему формату, что дан в разделе 3.1 RFC 822 [9].
Каждое поле заголовка состоит из имени, за которым следует двоеточие (":"), и поля значения. Поля имен безразличны в отношении использования строчных и прописных букв. Поле значения может начинаться с любого числа LWS, хотя один SP предпочтительнее. Поля заголовка могут занимать несколько строк, каждая новая строка должна открываться, по крайней мере, одним SP или HT. Рекомендуется, чтобы приложения следовали общему формату, если они создаются конструкциями HTTP, так как могут существовать некоторые реализации, которые не могут воспринимать ничего кроме общих форматов.
| Message-header | = field-name ":" [ field-value ] CRLF |
| field-name | = token |
| field-value | = *( field-content | LWS ) |
Порядок, в котором приходят поля заголовка с отличающимися именами, не играет значения. Однако, хорошей практикой считается посылка сначала поля общего заголовка, за которым следует заголовок запроса или отклика, а в заключение поля заголовка объекта.
Множественные поля заголовка сообщения с идентичными именами могут присутствовать тогда и только тогда, когда значение поля определяется как список из элементов, разделенных запятыми [то есть, #(значения)]. Должна быть предусмотрена возможность объединять множественные поля заголовка в одну пару "имя_поля: значение_поля", без изменения семантики сообщения, путем добавления каждой последующей пары поле-значение, отделенных друг от друга запятыми. Порядок, в котором следуют поля заголовка с идентичными именами, влияет на последующую интерпретацию значения комбинированного поля, по этой причине прокси-сервер не должен менять порядок значений этих полей при переадресации сообщения.
3.3. Тело сообщения
Тело сообщения HTTP (если имеется) используется для переноса тела объекта, сопряженного с запросом или откликом. Тело сообщения отличается от тела объекта, только когда используется транспортное кодирование, как это указано в поле заголовка Transfer-Encoding (раздел 13.40).
message-body = entity-body
|
Transfer- Encoding должно использоваться для указания любого транспортного кодирования, реализованного приложением с целью гарантированной неискаженной доставки сообщения. Транспортное кодирование лежит в зоне ответственности сообщения, а не объекта и по этой причине может быть реализовано любым приложением в цепочке запрос/отклик.
Присутствие тела сообщения в запросе отмечается с помощью включения полей заголовка Content-Length или Transfer-Encoding в заголовки сообщений-запросов. Тело сообщения может быть включено в запрос, только когда метод запроса допускает наличие тела объекта (раздел 4.1.1).
Для сообщений-откликов включение в них тела сообщения зависит от метода запроса и статусного кода отклика (раздел 5.1.1). Все отклики в случае метода запроса HEAD не должны включать тела сообщения, даже если присутствуют поля заголовка объекта, позволяющие предположить его присутствие. Все отклики 1xx (информационные), 204 (никакого содержимого) и 304 (не модифицировано) не должны включать тела сообщения. Все другие отклики включают в себя тело сообщения, хотя оно может иметь и нулевую длину.
3.4. Длина сообщения
Когда тело включено в сообщение, его длина определяется следующим образом (в порядке приоритета):
Любое сообщение-отклик, которое не должно включать в себя тело сообщения (такое как отклик 1xx, 204 и 304, а также любые отклики на запрос HEAD) всегда завершаются первой пустой строкой после полей заголовка, вне зависимости от присутствующих в сообщении полей заголовка объекта.
Если присутствует поле заголовка Transfer-Encoding (раздел 13.40) и указано, что использовано по фрагментное ("chunked") транспортное кодирование, тогда длина тела определяется выбранной схемой кодирования (раздел 2.6).
Если присутствует поле заголовка Content-Length (раздел 13.14), его значение в байтах и определяет длину тела сообщения.
Если сообщение использует тип cреды "multipart/byteranges", который является самоограничивающим, тогда он и определяет длину.
Этот тип среды не должен использоваться, если отправитель не знает, может ли получатель разобрать его. Присутствие в запросе заголовка Range с множественными спецификаторами диапазона подразумевает, что клиент может разобрать отклики типа multipart/byteranges.
Определяется сервером при закрытии связи. (Закрытие соединения не может использоваться для обозначения конца тела запроса, так как это не оставит возможности для сервера послать отклик.)
Для совместимости с приложениями HTTP/1.0, запросы HTTP/1.1, содержащие тело запроса, должны включать корректное поле заголовка Content-Length. Если запрос содержит тело сообщения, а поле Content-Length отсутствует, рекомендуется, чтобы сервер реагировал откликом 400 (плохой запрос), если он не может определить длину сообщения, или 411 (необходима длина), если он настаивает на получении корректного поля Content-Length.
Все приложения HTTP/1.1, которые получают объект (entity) должны понимать блочное ("chunked") транспортное кодирование (раздел 2.6), таким образом, разрешая использование этого механизма для сообщений, когда длина сообщения не может быть определена заранее.
Сообщения не должны включать поле заголовка Content-Length и блочное транспортное кодирование одновременно. Если такое сообщение получено, поле Content-Length должно игнорироваться.
Когда в сообщении присутствует поле Content-Length и разрешено наличие тела сообщения, его значение поля должно строго соответствовать числу октетов в теле сообщения. Агенты пользователя HTTP/1.1 должны оповещать пользователя, если получено сообщение некорректной длины.
3.5. Общие поля заголовка
Существует несколько полей заголовка, которые имеют применимость, как для запросов, так и откликов, но которые не используются для передачи объектов. Эти поля заголовков служат только для пересылаемых сообщений.
| general-header | = Cache-Control | ; Раздел 13.9 |
| | Connection | ; Раздел 13.10 | |
| | Date | ; Раздел 13.19 | |
| | Pragma | ; Раздел 13.32 | |
| | Transfer-Encoding | ; Раздел 13.40 | |
| | Upgrade | ; Раздел 13.41 | |
| | Via | ; Раздел 13.44 |
/p> Имена полей общего заголовка могут быть расширены только при изменении версии протокола. Однако, новые или экспериментальные поля заголовка могут использоваться при условии, если партнеры обмена способны их распознавать, как поля общего заголовка. Не узнанные поля заголовка считаются полями заголовка объекта (entity).
4.5.6.1.4. Запрос
Сообщение-запрос от клиента к серверу включает в себя, в пределах первой строки сообщения, метод, который должен быть использован для ресурса, идентификатор ресурса и код версии используемого протокола.
| Request | = Request-Line | |
| *( generalheader | ||
| | requestheader | ||
| | entityheader ) | ||
| CRLF | ||
| [ messagebody ] |
Строка запроса начинается с лексемы метода, за которой следует Request-URI, версия протокола, завершается строка последовательностью CRLF. Элементы разделяются символами SP. Символы CR или LF запрещены кроме завершающей последовательности CRLF.
| Request | Line = Method SP Request-URI SP HTTP-Version CRLF |
Лексема Method указывает на метод, который должен быть применен к ресурсу, обозначенному Request-URI. При записи метода использование строчных или прописных букв не безразлично.
| Method | = "OPTIONS" | ; Раздел 9.2 |
| | "GET" | ; Раздел 9.3 | |
| | "HEAD" | ; Раздел 9.4 | |
| | "POST" | ; Раздел 9.5 | |
| | "PUT" | ; Раздел 9.6 | |
| | "DELETE" | ; Раздел 9.7 | |
| | "TRACE" | ; Раздел 9.8 | |
| | extension-method extension-method = token |
Методы GET и HEAD должны поддерживаться всеми серверами общего назначения. Все другие методы являются опционными; однако, если применены вышеназванные методы, они должны быть применены с той же семантикой, что специфицирована в разделе 8.
5.1.2 URI запроса
URI запроса является универсальным идентификатором ресурса (раздел 2.2) и идентифицирует ресурс, который запрашивается.
Request-URI = "*" | absoluteURI | abs_path
Три опции для Request-URI зависят от природы запроса. Звездочка "*" означает, что запрос приложим не к заданному ресурсу, но к самому серверу, и допустим только, когда используемый метод не обязательно приложим к ресурсу. Примером может служить
OPTIONS * HTTP/1.1
Форма абсолютного URI необходима, когда запрос адресован к прокси-серверу. Прокси-серверу посылается запрос переадресации с целью получения отклика. Заметьте, что прокси может переадресовать запрос другому прокси или серверу, указанному абсолютным URI. Для того, чтобы избежать петель запросов прокси-сервер должен быть способен распознавать все имена серверов, включая любые псевдонимы, локальные вариации и численные IP-адреса. Пример строки запроса представлен ниже:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
Для того чтобы разрешить передачу абсолютных URI в запросах будущих версий HTTP, все серверы HTTP/1.1 должны уметь работать с запросами абсолютных форм URI.
Наиболее общей формой Request-URI является та, которая используется для идентификации ресурса на исходном сервере или внешнем порту сети. В этом случае абсолютный проход к URI должен быть занесен в abs_path (см. раздел 2.2.1) как Request-URI, а сетевой адрес URI (net_loc) должен быть занесен в поле заголовка Host. Например, клиент, желающий извлечь ресурс из выше приведенного примера непосредственно с базового сервера, установит TCP-соединение через порт 80 с ЭВМ "www.w3.org" и пошлет строки:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
за которыми следует остальная часть запроса.
Заметьте, что абсолютный проход не может быть пустым; если его нет в исходном URI, он должен быть задан в виде "/" (корневой каталог сервера).
Если прокси получает запрос без какого-либо прохода в Request-URI, а метод, специфицирован так, чтобы быть способным поддерживать форму “*” запросов, тогда последний прокси в цепочке запроса должен переадресовать запрос с "*" в качестве финального Request-URI. Например, запрос
OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1
будет переадресован прокси как
OPTIONS * HTTP/1.1
Host: www.ics.uci.edu:8001
после подключения к порту 8001 ЭВМ "www.ics.uci.edu".
Request-URI передается в формате, описанном в разделе 3.2.1. Исходный сервер должен декодировать Request-URI, для того чтобы правильно интерпретировать запрос. Серверам рекомендуется откликаться на некорректный запрос Request-URI соответствующим статусным кодом.
В запросах, которые они переадресуют, прокси-серверы не должны переписывать "abs_path" часть Request-URI каким-либо способом, за исключением случая, описанного выше, когда нулевой abs_path заменяется на "*".
Замечание: Правило "no rewrite" препятствует прокси изменить смысл запроса, когда исходный сервер некорректно использует незарезервированный URL символ для зарезервированных целей. Следует остерегаться того, что некоторые предшествующие варианты прокси-серверов HTTP/1.1 допускали перезапись Request-URI.
4.2. Ресурс, идентифицируемый запросом
Исходному серверу HTTP/1.1 рекомендуется заботиться о точном определении ресурса, идентифицированного Интернет-запросом путем анализа Request-URI и поля заголовка Host.
Исходный сервер, который не разделяет ресурсы по запрашиваемого ЭВМ, может игнорировать значение поля заголовка Host. (См. раздел 16.5.1 по поводу других требований по поддержке Host в HTTP/1.1.)
Исходный сервер, который различает ресурсы с использованием имени ЭВМ, должен использовать следующие правила для определения ресурса в запросе HTTP/1.1:
Если Request- URI является absoluteURI, ЭВМ определена частью Request-URI. Любое значение поля заголовка Host в запросе должно игнорироваться.
Если Request-URI не является absoluteURI, а запрос содержит поле заголовка Host, ЭВМ определяется значением поля заголовка Host.
Если ЭВМ, так как это определено правилами 1 или 2, не является ЭВМ сервера, откликом должно быть сообщение об ошибке с кодом 400 (Плохой запрос - Bad Request).
Получатели HTTP/1.0-запроса, где отсутствует поле заголовка Host, могут попытаться использовать эвристику (напр., рассмотрение прохода URI на предмет уникальной конкретной ЭВМ) для того, чтобы определить, какой конкретный ресурс запрошен.
4.3. Поля заголовка запроса
Поля заголовка запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте. Эти поля действуют как модификаторы запроса, с семантикой, эквивалентной параметрам, характеризующими метод языка программирования.
| Request-header | = Accept | ; Раздел 13.1 |
| | Accept-Charset | ; Раздел 13.2 | |
| | Accept-Encoding | ; Раздел 13.3 | |
| | Accept-Language | ; Раздел 13.4 | |
| | Authorization | ; Раздел 13.8 | |
| | From | ; Раздел 13.22 | |
| | Host | ; Раздел 13.23 | |
| | If-Modified-Since | ; Раздел 13.24 | |
| | If-Match | ; Раздел 13.25 | |
| | If-None-Match | ; Раздел 13.26 | |
| | If-Range | ; Раздел 13.27 | |
| | If-Unmodified-Since | ; Раздел 13.28 | |
| | Max-Forwards | ; Раздел 13.31 | |
| | Proxy-Authorization | ; Раздел 13.34 | |
| | Range | ; Раздел 13.36 | |
| | Referer | ; Раздел 13.37 | |
| | User-Agent | ; Раздел 13.42 |
4.5.6.1.5. Отклик
После получения и интерпретации сообщения-запроса, сервер реагирует, посылая HTTP сообщение отклик.
| Response | = Status-Line | ; Раздел 5.1 |
| *( general-header | ; Раздел 3.5 | |
| | response-header | ; Раздел 5.2 | |
| | entity-header ) | ; Раздел 6.1 | |
| CRLF | ||
| [ message-body ] | ; Раздел 6.2 |
Первая строка сообщения- отклика является статусной строкой, состоящей из кода версии протокола, за которым следует числовой статусный код и его текстовое представление, все элементы разделяются символами SP (пробел). Никакие CR или LF не допустимы, за исключением завершающей последовательности CRLF.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
5.1.1. Статусный код и словесный комментарий
Элемент Status-Code представляет собой 3-значный цифровой результирующий код попытки понять и исполнить запрос. Эти коды полностью определены в разделе 9. Словесный комментарий (Reason-Phrase) предназначен для того, чтобы дать краткое описание статусного кода. Статусный код служит для использования автоматами, а словесный комментарий для пользователей. Клиент не обязан рассматривать или отображать словесный комментарий.
Первая цифра статусного кода определяет класс отклика. Последние две цифры не имеют четко определенной функции. Существует 5 значений первой цифры:
1xx: Информационный – Запрос получен, процесс продолжается
2xx: Успех (Success) – Запрос успешно получен, понят и воспринят
3xx: Переадресация (Redirection) – Нужны дополнительные действия для завершения выполнения запроса
4xx: Ошибка клиента (Client Error) – Запрос содержит синтаксическую ошибку или не может быть выполнен
5xx: Ошибка сервера (Server Error) – Сервер не смог выполнить корректный запрос
Индивидуальные значения числовых статусных кодов определены в HTTP/1.1, а набор примеров, соответствующих причинам, представлен ниже. Комментарии причин, предлагаемые здесь, являются лишь рекомендательными – они могут быть заменены местными аналогами без последствий для протокола.
| Status-Code | = "100" | ; Continue |
| | "101" | ; Switching Protocols | |
| | "200" | ; OK | |
| | "201" | ; Created | |
| | "202" | ; Accepted | |
| | "203" | ; Non-Authoritative Information | |
| | "204" | ; No Content | |
| | "205" | ; Reset Content | |
| | "206" | ; Partial Content | |
| | "300" | ; Multiple Choices | |
| | "301" | ; Moved Permanently | |
| | "302" | ; Moved Temporarily | |
| | "303" | ; See Other | |
| | "304" | ; Not Modified | |
| | "305" | ; Use Proxy | |
| | "400" | ; Bad Request | |
| | "401" | ; Unauthorized | |
| | "402" | ; Payment Required | |
| | "403" | ; Forbidden | |
| | "404" | ; Not Found | |
| | "405" | ; Method Not Allowed | |
| | "406" | ; Not Acceptable | |
| | "407" | ; Proxy Authentication Required | |
| | "408" | ; Request Time-out | |
| | "409" | ; Conflict | |
| | "410" | ; Gone | |
| | "411" | ; Length Required | |
| | "412" | ; Precondition Failed | |
| | "413" | ; Request Entity Too Large | |
| | "414" | ; Request-URI Too Large | |
| | "415" | ; Unsupported Media Type | |
| | "500" | ; Internal Server Error | |
| | "501" | ; Not Implemented | |
| | "502" | ; Bad Gateway | |
| | "503" | ; Service Unavailable | |
| | "504" | ; Gateway Time-out | |
| | "505" | ; HTTP Version not supported | |
| | extension-code |
/p>
| Extension-code | = 3DIGIT |
| Reason-Phrase | = * |
5.2 Поля заголовка отклика
Поля заголовка отклика позволяют серверу передавать дополнительную информацию об отклике, который не может быть помещен в статусную строку. Эти поля заголовка дают информацию о сервере и доступе к ресурсу, идентифицированному Request-URI.
| Response-header | = Age | ; Раздел 13.6 |
| | Location | ; Раздел 13.30 | |
| | Proxy-Authenticate | ; Раздел 13.33 | |
| | Public | ; Раздел 13.35 | |
| | Retry-After | ; Раздел 13.38 | |
| | Server | ; Раздел 13.39 | |
| | Vary | ; Раздел 13.43 | |
| | Warning | ; Раздел 13.45 | |
| | WWW-Authenticate | ; Раздел 13.46 |
4.5.6.1.6. Объект (Entity)
Сообщения запрос и отклик могут нести в себе объект, если это не запрещено методом запроса или статусным кодом отклика. Объект состоит из полей заголовка объекта и тела объекта, хотя некоторые отклики включают в себя только заголовки объектов.
В данном разделе, как отправитель, так и получатель соотносятся к клиенту или серверу, в зависимости от того, кто отправляет и кто получает объект.
6.1. Поля заголовка объекта
Поля заголовка объекта определяют опционную метаинформацию о теле объекта или, если тело отсутствует, о ресурсе, идентифицированном в запросе.
| Entity-header | = Allow | ; Раздел 13.7 |
| | Content-Base | ; Раздел 13.11 | |
| Entity-header | | Content- | ; Раздел 13.12 |
| Entity-header | | Content-Language | ; Раздел 13.13 |
| Entity-header | | Content-Length | ; Раздел 13.14 |
| Entity-header | | Content-Location | ; Раздел 13.15 |
| Entity-header | | Content-MD5 | ; Раздел 13.16 |
| Entity-header | | Content-Range | ; Раздел 13.17 |
| Entity-header | | Content-Type | ; Раздел 13.18 |
| Entity-header | | Etag | ; Раздел 13.20 |
| Entity-header | | Expires | ; Раздел 13.21 |
| Entity-header | | Last-Modified | ; Раздел 13.29 |
| Entity-header | | extension-header |
Механизм расширения заголовка позволяет определить дополнительные полязаголовка объекта без изменения версии протокола, но эти поля не могут считаться заведомо распознаваемыми получателем. Неузнанные поля заголовка рекомендуется получателю игнорировать и переадресовывать прокси-серверам.
6.2. Тело объекта
Тела объекта (если они имеются), пересылаемые HTTP-запросом или откликом, имеют формат и кодировку, определенную полями заголовка объекта.
| entity-body | = *OCTET |
6.2.1. Тип
Когда тело объекта включено в сообщение, тип данных этого тела определяется полями заголовка Content-Type и Content-Encoding. Они определяют два слоя, заданных моделью кодирования:
entity-body := Content-Encoding( Content-Type( данные ) )
Content-Type специфицирует тип среды данных.
Content-Encoding может использоваться для индикации любого дополнительного кодирования содержимого поля данных, обычно для целей архивации, которая является особенностью запрашиваемого ресурса.
По умолчанию никакого кодирования не используется.
Любое HTTP/1.1 сообщение, содержащее тело объекта, должно включать поле заголовка Content-Type, определяющее тип среды для данного тела. Только в случае, когда тип среды не задан полем Content-Type, получатель может попытаться предположить, каким является тип среды, просмотрев содержимое и/или расширения имен URL, использованного для идентификации ресурса. Если тип среды остается неизвестным, получателю следует рассматривать его как "application/octet-stream" (поток октетов).
6.2.2. Длина
Длина тела объекта равна длине тела сообщения, после того как произведено транспортное декодирование. Раздел 4.4 определяет то, как определяется длина тела сообщения.
4.5.6.1.7. Соединения
7.1. Постоянные соединения
7.1.1. Цель
Прежде чем установить постоянную связь должно быть реализовано отдельное TCP соединение с тем, чтобы получить URL. Это увеличивает нагрузку HTTP серверов и вызывает перегрузку каналов Интернет. Использование изображений и другой связанной с этим информации часто требует от клиента множественных запросов, направленных определенным серверам за достаточно короткое время. Анализ этих проблем содержится в [30][27], а результаты макетирования представлены в [26].
Постоянное HTTP соединение имеет много преимуществ:
При открытии и закрытии TCP соединений можно сэкономить время CPU и память, занимаемую управляющими блоками протокола TCP.
HTTP запросы и отклики могут при установлении связи буферизоваться (pipelining), образуя очередь. Буферизация позволяет клиенту выполнять множественные запросы, не ожидая каждый раз отклика на запрос, используя одно соединение TCP более эффективно и с меньшими потерями времени.
Перегрузка сети уменьшается за счет сокращения числа пакетов, сопряженных с открытием и закрытием TCP соединений, предоставляя достаточно времени для детектирования состояния перегрузки.
HTTP может функционировать более эффективно, так как сообщения об ошибках могут доставляться без потери TCP связи.
Клиенты, использующие будущие версии HTTP, могут испытывать новые возможности, взаимодействуя со старым сервером, они могут после неудачи попробовать старую семантику. HTTP реализациям следует пользоваться постоянными соединениями.
7.1.2. Общие процедуры
Заметным различием между HTTP/1.1 и более ранними версиями HTTP является постоянное соединение, которое в HTTP/1.1 является вариантом, реализуемым по умолчанию. Поэтому, если не указано обратное, клиент может предполагать, что сервер будет поддерживать постоянное соединение.
Постоянное соединение обеспечивает механизм, с помощью которого клиент и сервер могут сигнализировать о закрытии TCP-соединения. Эта система сигнализации использует поле заголовка Connection. Как только поступил сигнал о закрытии канала, клиент не должен посылать какие-либо запросы по этому каналу.
7.1.2.1. Согласование
HTTP/1.1 сервер может предполагать, что HTTP/1.1 клиент намерен поддерживать постоянное соединение, если только в поле заголовка Connection не записана лексема "close". Если сервер принял решение закрыть связь немедленно после посылки отклика, ему рекомендуется послать заголовок Connection, включающий лексему связи close.
Клиент HTTP/1.1 может ожидать, что соединение останется открытым, но примет решение оставлять ли его открытым на основе того, содержит ли отклик сервера заголовок Connection с лексемой close.
Если клиент или сервер посылает лексему close в заголовке Connection, этот запрос становится последним для данного соединения.
Клиентам и серверам не следует предполагать, что соединение будет оставаться постоянным для версий HTTP, меньше 1.1, если только не получено соответствующее уведомление.
7.1.2.2. Буферизация
Клиенты, которые поддерживают постоянное соединение, могут буферизовать свои запросы (то есть, посылать несколько запросов не дожидаясь отклика для каждого из них). Серверы должны посылать свои отклики на эти запросы в том же порядке, в каком они их получили.
Клиенты, которые предполагают постоянство соединения и буферизацию немедленно после установления соединения должны быть готовы совершить повторную попытку установить связь, если первая буферизованная попытка не удалась.
Если клиент совершает повторную попытку установления связи, он не должен выполнять буферизацию запросов, пока не получит подтверждения об установления постоянного соединения. Клиенты должны также быть готовы послать повторно свои запросы, если сервер закрывает соединение прежде, чем пришлет соответствующие отклики.
7.1.3. Прокси-серверы
Особенно важно то, чтобы прокси-серверы корректно использовали свойства поля заголовка Connection, как это специфицировано в 13.2.1.
Прокси-сервер должен сигнализировать о постоянном соединении отдельно своему клиенту и исходному серверу (origin server) или другому прокси, с которым связан. Каждое постоянное соединение устанавливается только для одной транспортной связи.
Прокси-сервер не должен устанавливать постоянное соединение с HTTP/1.0 клиентом.
7.1.4. Практические соображения
Серверы обычно имеют некоторое значение таймаута, за пределами которого они уже не поддерживают более неактивное соединение. Прокси-серверы могут сделать эту величины больше, так как весьма вероятно, что клиент создаст больше соединений через один и тот же сервер. Использование постоянных соединений не устанавливает никаких требований на величину этого таймаута для клиента или сервера.
Когда клиент или сервер хочет прервать связь по таймауту, ему следует послать корректное оповещение о закрытии соединения. Клиенты и серверы должны постоянно следить, не выдала ли противоположная сторона сигнал на закрытие канала и соответственно реагировать на него. Если клиент или сервер не зафиксирует сигнал противоположной стороны, то будут бессмысленно тратиться ресурсы сети.
Клиент, сервер или прокси могут закрыть транспортный канал в любое время. Например, клиент может послать новый запрос во время, когда сервер решит закрыть "пассивное" соединение. С точки зрения сервера, состояние которое предлагается закрыть, является пассивным, но с точки зрения клиента идет обработка запроса.
Это означает, что клиенты, серверы и прокси должны быть способны восстанавливаться после случаев асинхронного закрытия.
Программа клиента должна заново открыть транспортное соединение и повторно передать неисполненный запрос без вмешательства пользователя (см. раздел 1.2), хотя агент пользователя может предложить оператору выбор, сопряженный с повторением запроса. Однако эта повторная попытка не должна повторяться при повторной неудаче.
Серверам следует всегда реагировать, по крайней мере, на один запрос при соединении, если это возможно. Серверам не следует закрывать соединение в процессе передачи отклика, если только не имеет место отказ в сети или выключение клиента.
Клиенты, которые используют постоянные соединения, должны ограничивать число одновременных связей, которые они поддерживают с конкретным сервером. Однопользовательскому клиенту рекомендуется поддерживать не более двух соединений с любым сервером или прокси. Прокси следует использовать до 2*N соединений с другим сервером или прокси, где N равно числу активных пользователей. Эти рекомендации призваны улучшить время отклика HTTP и исключить перегрузки Интернет и других сетей.
7.2. Требования к передаче сообщений
Общие требования:
HTTP/1.1 серверам следует поддерживать постоянные соединения и использовать TCP механизмы контроля информационного потока для преодоления временных перегрузок, а не разрывать соединение в расчете на то, что клиент совершит повторную попытку. Последнее может усугубить сетевую перегрузку.
Клиент HTTP/1.1 (или позднее), посылая тело сообщения, должен мониторировать сетевое соединение на наличие сигнала ошибки. Если клиент обнаружил состояние ошибки, он должен немедленно прервать передачу. Если тело передается с использованием блочной кодировки ("chunked" encoding, раздел 2.6), возможно применение фрагмента нулевой длины и пустой завершающей секции для обозначения преждевременного конца сообщения. Если телу предшествовал заголовок Content-Length, клиент должен разорвать соединение.
Клиент HTTP/1.1 (или позднее) должен быть готов принять код статуса 100 (Continue - продолжить), за которым следует обычный отклик.
Сервер HTTP/1.1 (или позднее), который получает запрос от клиента HTTP/1.0 (или ранее), не должен передавать отклик 100 (continue - продолжение), ему следует или ждать нормального завершения запроса (таким образом, избегая его прерывания) или преждевременно разрывать соединение.
Клиентам следует запомнить номер версии, по крайней мере, сервера, с которым проводилась работа последним, если клиент HTTP/1.1 получил отклик от сервера HTTP/1.1 (или позднее) и обнаружил разрыв соединения до получения какого-либо статусного кода, клиенту следует повторно попытаться направить запрос без участия пользователя (см. раздел 9.1.2). Если клиент действительно повторяет запрос, то клиент:
Должен сначала послать поля заголовка запроса, а затем
Должен ждать, того, что сервер пришлет отклик 100 (Continue), тогда клиент продолжит работу, или код статуса, сигнализирующего об ошибке.
Если клиент HTTP/1.1 не получил отклика от сервера HTTP/1.1 (или более поздней версии), ему следует считать, что сервер поддерживает версию HTTP/1.0 или более раннюю и не использует отклик 100 (Continue). Если в этом случае клиент обнаруживает закрытие соединения до получения какого-либо статусного кода от сервера, клиенту следует повторить запрос. Если клиент повторил запрос серверу HTTP/1.0, ему следует использовать следующий алгоритм получения надежного отклика:
Инициировать новое соединение с сервером
Передать заголовок запроса
Инициализировать переменную R для оценки задержки отклика сервера (round-trip time) (напр., на основе времени установления соединения), если RTT не доступно, ему присваивается значение 5 секунд.
Вычислить T = R * (2**N), где N равно числу предыдущих попыток запроса.
Ждать в течение Т секунд или до прихода статуса ошибки (что наступит раньше)
Если не получен сигнал ошибки, после T секунд передается тело запроса.
Если клиент обнаруживает преждевременное прерывание связи, повторяется шаг 1 до тех пор, пока запрос не будет принят или будет получен сигнал ошибки, или пока нетерпеливый пользователь не завершит процесс посылки повторных запросов.
Вне зависимости от версии сервера, если получен статус ошибки, то клиент
Не должен продолжать операции и
Должен прервать соединение, если процедура не завершена посылкой сообщения.
Клиент HTTP/1.1 (или позднее), который обнаруживает разрыв соединения после получения флага 100 (Continue), но до получения какого-либо статусного кода, должен повторить запрос и не должен ждать отклика 100 (Continue), но может и делать это, если это упрощает реализацию программы.
4.5.6.1.8. Метод определений
Набор общих методов для HTTP/1.1 определен ниже. Хотя этот набор может быть расширен, нельзя предполагать, что дополнительные методы следуют той же семантике для разных клиентов и серверов. Поле заголовка запроса Host (раздел 13.23) должно присутствовать во всех запросах HTTP/1.1.
8.1. Безопасные и Idempotent методы
8.1.1. Безопасные методы
Программисты должны заботиться о том, чтобы избегать операций, которые могут иметь неожиданное значение для них самих или их соседей по сети Интернет.
В частности, установлено соглашение, что методы GET и HEAD никогда не должны выполнять какие либо функции помимо доставки информации. Эти методы должны рассматриваться как вполне безопасные. Это позволяет агентам пользователя представлять другие методы, такие как POST, PUT и DELETE, особым способом, так что пользователь сам будет заботиться о возможности опасных операций, которые могут быть выполнены в результате реализации запроса.
Естественно, невозможно гарантировать, что сервер не будет вызывать побочные эффекты, как следствие выполнения запроса GET; в действительности, некоторые динамические ресурсы предусматривают такую возможность. Важным отличием здесь является то, что пользователь не запрашивал побочные эффекты и, следовательно, не может нести ответственность за них.
8.1.2. Подобные методы
Методы могут также иметь свойство "idempotence", при котором (помимо ошибок и таймаутов) побочный эффект от N > 0 идентичных запросов является таким же, как и от одного запроса.
Методы GET, HEAD, PUT и DELETE имеют это свойство.
8.2. Опции
Метод OPTIONS представляет собой запрос информации о коммуникационных опциях, доступных в цепочке запрос/отклик, идентифицированной Request-URI. Этот метод позволяет клиенту определить опции и/или требования, связанные с ресурсами, или возможности сервера, не прибегая к операциям по извлечению и пересылке каких-либо файлов.
Если отклик сервера не сигнализирует об ошибке, отклик не должен включать никакой информации об объекте, отличной оттого, что считается коммуникационными опциями (напр., Allow подходит под эту категорию, а Content-Type нет). Отклики на этот метод не должны кэшироваться.
Если Request-URI тождественен символу звездочка ("*"), то запрос OPTIONS будет относиться ко всему серверу. Отклик 200 должен включать в себя любые поля заголовка, которые указывают на опционные характеристики используемого сервера (например, Public), включая любые расширения неопределенные в данной спецификации, в дополнение к любым общим используемым полям заголовка. Как описано в разделе 4.1.2, запрос "OPTIONS *" может быть реализован через прокси путем спецификации сервера места назначения в Request-URI без указания прохода. Если Request-URI не равен звездочке, запрос OPTIONS относится только к опциям, которые доступны при обмене с данным ресурсом. Отклик 200 должен включать любые поля заголовка, которые указывают опционные характеристики используемого сервера и применимы к данному ресурсу (напр., Allow), включая любые расширения, не описанные в данной спецификации. Если запрос OPTIONS проходит через прокси, то он должен редактировать отклик и удалять те опции, которые не доступны для реализации через данный прокси-сервер.
8.3 Метод GET
Метод GET предполагает извлечение любой информации (в форме объекта), заданной Request-URI. Если Request-URI относится к процессу, генерирующему данные, то в результате в виде объекта будут присланы эти данные, а не исходный текст самого процесса, если только этот текст не является результатом самого процесса.
Семантика метода меняется на "условный GET", если сообщение-запрос включает в себя поля заголовка If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match или If-Range. Метод условного GET запрашивает, пересылку объекта только при выполнении требований, описанных в соответствующих полях заголовка. Метод условного GET имеет целью уменьшить ненужное использование сети путем разрешения актуализации кэшированых объектов без посылки множественных запросов или пересылки данных, которые уже имеются у клиента. Семантика метода GET меняется на "частичный GET", если сообщение запроса включает в себя поле заголовка Range. Запросы частичного GET, которые предназначены для пересылки лишь части объекта, описаны в разделе 13.36. Метод частичного GET ориентирован на уменьшение ненужного сетевого обмена, допуская пересылку лишь части объекта, которая нужна клиенту, и не пересылая уже имеющихся частей.
Отклик на запрос GET буферизуется, тогда и только тогда, когда это согласуется с требованиями буферизации, рассмотренными в разделе 12.
8.4. Метод HEAD
Метод HEAD идентичен GET за исключением того, что сервер не должен присылать тело сообщения. Метаинформация, содержащаяся в заголовках отклика на запрос HEAD должна быть идентичной информации посланной в отклик на запрос GET. Этот метод может использоваться для получения метаинформации об объекте, указанном в запросе, без передачи тела самого объекта. Этот метод часто используется для тестирования гипертекстных связей на корректность, доступность и актуальность.
Отклик на запрос HEAD может кэшироваться в том смысле, что информация, содержащаяся в отклике, может использоваться для актуализации кэшированных ранее объектов данного ресурса. Если новые значения поля указывают на то, что кэшированный объект отличается от текущего объекта (как это индицируется изменением Content-Length, Content-MD5, ETag или Last-Modified), тогда запись в кэше должна рассматриваться как устаревшая.
8.5. Метод POST
Метод POST используется при заявке серверу принять вложенный в запрос объект в качестве нового вторичного ресурса, идентифицированного Request-URI в Request-Line.
POST создан для обеспечения однородной схемы реализации следующих функций:
Аннотация существующего ресурса;
Помещение сообщения на электронную доску объявлений, в группу новостей, почтовый список или какую-то другую группу статей;
Выдача блока данных, такого как при передаче формы процессу ее обработки;
Расширение базы данных с помощью операции добавления (append).
Реальная операция, выполняемая методом POST, определяется сервером и обычно зависит от Request-URI. Присланный объект является вторичным по отношению к URI в том же смысле, в каком файл является вторичным по отношению к каталогу, в котором он находится, а статья новостей - вторичной по отношению к группе новостей, куда она помещена, или запись – по отношению к базе данных.
Операция, выполняемая методом POST, может не иметь последствий для ресурса, который может быть идентифицирован URI. В этом случае приемлемым откликом является 200 (OK) или 204 (No Content – никакого содержимого), в зависимости от того, включает ли в себя отклик объект, описывающий ресурс.
Если ресурс был создан на исходном сервере, отклик должен быть равен 201 (Created - создан) и содержать объект, который описывает статус запроса и относится к новому ресурсу и заголовку Location (см. раздел 13.30).
Отклики на этот метод не могут кэшироваться, если только не содержат поля заголовка Cache-Control или Expires. Однако отклик 303 (см. Other) может быть использован для того, чтобы направить агента пользователя для извлечения кэшируемого ресурса.
Запросы POST должны подчиняться требованиям, предъявляемым к передаче сообщений, рассмотренным в разделе 7.2.
8.6. Метод PUT
Метод PUT требует, чтобы вложенный объект был запомнен с использованием Request-URI. Если Request-URI относится к уже существующему ресурсу, то вложенный объект следует рассматривать как модифицированную версию объекта на исходном сервере. Если Request-URI не указывает на существующий ресурс и запрашивающий агент пользователя может определить этот URI как новый ресурс, исходный сервер может создать ресурс с этим URI.
Если новый ресурс создан, исходный сервер должен информировать об этом агента пользователя, послав код отклик 200 (OK) или 204 (No Content – никакого содержимого) и тем самым, объявляя об успешно выполненном запросе. Если ресурс не может быть создан или модифицирован с помощью Request-URI, должен быть послан соответствующий код отклика, который отражает характер проблемы. Получатель объекта не должен игнорировать любой заголовок Content-* (например, Content-Range), который он не понял или не использовал, а должен в таком случае вернуть код отклика 501 (Not Implemented – не использовано).
Если запрос проходит через кэш и Request-URI идентифицирует один или более кэшированных объектов, эти объекты должны рассматриваться как устаревшие. Отклики этого метода не должны кэшироваться.
Фундаментальное отличие между запросами POST и PUT отражается в различных значениях Request-URI. URI в запросе POST идентифицирует ресурс, который будет работать со вложенным объектом. Этот ресурс может быть процессом приемки данных, шлюзом к другому протоколу или отдельным объектом, который воспринимает аннотации. Напротив, URI в запросах PUT идентифицируют объекты, заключенные в запросе, – агент пользователя знает, какой URI применить и сервер не должен пытаться посылать запрос другому ресурсу. Если сервер хочет, чтобы запрос был направлен другому URI, он должен послать отклик 301 (Moved Permanently). Агент пользователя может принять свое собственное решение относительно того, следует ли переадресовывать запрос.
Один и тот же ресурс может быть идентифицирован многими URI. Например, статья может иметь URI для идентификации "текущей версии", которая отличается от URI, идентифицирующей каждую конкретную версию. В этом случае запрос PUT на общий URI может дать в результате несколько других URI, определенных исходным сервером. HTTP/1.1 не определяет то, как метод PUT воздействует на состояние исходного сервера. Запросы PUT должны подчиняться требованиям передачи сообщения, заданным в разделе 7.2.
8.7. Метод DELETE
Метод DELETE требует, чтобы исходный сервер уничтожил ресурс, идентифицируемый Request-URI. Этот метод на исходном сервере может быть отвергнут вмешательством человека (или каким-то иным путем). Клиент не может гарантировать, что операция была выполнена, даже если возвращенный статусный код указывает, что операция завершилась успешно. Однако, сервер не должен сообщать об успехе, если за время отклика он не намерен стереть ресурс или переместить его в недоступное место.
Сообщение об успехе должно иметь код 200 (OK), если отклик включает объект, описывающий статус; 202 (Accepted - принято), если операция еще не произведена или 204 (No Content – Никакого содержимого), если отклик OK, но объекта в нем нет.
Если запрос проходит через кэш, а Request-URI идентифицирует один или более кэшированных объектов, эти объекты следует считать устаревшими (stale). Отклики на этот метод не кэшируемы.
8.8. Метод TRACE
Метод TRACE используется для того, чтобы запустить удаленный цикл сообщения-запроса на прикладном уровне. Конечный получатель запроса должен отослать полученное сообщение назад клиенту в виде тела объекта (код = 200 (OK)). Конечным получателем является либо исходный сервер, либо первый прокси или шлюз для получения значения Max-Forwards (0) в запросе (см. раздел 13.31). Запрос TRACE не должен включать в себя объект.
TRACE позволяет клиенту видеть, что получено на другом конце цепи запроса и использовать эти данные для тестирования или диагностики. Значение поля заголовка Via (раздел 13.44) представляет особый интерес, так как оно позволяет отследить всю цепочку запроса. Использование поля заголовка Max-Forwards позволяет клиенту ограничить длину цепи запроса, которая полезна для тестирования цепи прокси, переадресующих сообщения по замкнутому кругу.
В случае успеха отклик должен содержать все сообщение-запрос с Content-Type = "message/http". Отклики этого метода не должны кэшироваться.
4.5.6.1.9. Определения статусных кодов
Ниже описаны статусные коды, включая то, каким методам они соответствуют, и какая метаинформация должна присутствовать в откликах.
9.1. Информационный 1xx
Этот класс статусного кода индицирует информационный отклик, состоящий только из статусной строки и опционных заголовков с пустой строкой в конце. Так как HTTP/1.0 не определяет каких-либо статусных кодов 1xx, серверы не должны посылать отклики 1xx клиентам HTTP/1.0 за исключением случаев отладки экспериментальных протокольных версий.
9.1.1. 100 Continue (продолжение)
Клиент может продолжать работу, получив этот отклик. Этот промежуточный отклик используется для информирования клиента о том, что начальная часть запроса получена и пока не отклонена сервером. Клиенту следует продолжить отправлять оставшуюся часть запроса, если же запрос уже отправлен, то игнорировать этот отклик. Сервер должен послать окончательный отклик по завершении реализации запроса.
9.1.2. 101 Switching Protocols (Переключающие протоколы)
Сервер оповещает клиента о том, что он понял и принял к исполнению запрос. С помощью поля заголовка сообщения Upgrade (раздел 13.41) клиент уведомляется об изменении прикладного протокола для данного соединения. Сервер переходит на протокол, определенный в поле заголовка отклика Upgrade, немедленно после получения пустой строки, завершающей отклик 101.
Протокол следует изменять лишь в случае, если он предоставляет существенные преимущества. Например, переключение на новую версию HTTP предоставляет преимущества по отношению к старой версии, а переключение на синхронный протокол реального времени может иметь преимущество, когда ресурс использует это свойство.
9.2. Successful 2xx (Успешная доставка)
Этот класс статусного кода индицирует, что запрос клиента благополучно получен, понят и принят к исполнению.
9.2.1. 200 OK
Запрос успешно исполнен. Информация, возвращаемая вместе с откликом, зависит от метода, использованного запросом, например:
GET - в качестве отклика посылается объект, соответствующий запрошенному ресурсу;
HEAD – в качестве отклика посылаются поля заголовка объекта (без какого-либо тела), соответствующего запрошенному ресурсу;
POST - объект, описывающий или содержащий результат операции;
TRACE – объект, содержащий сообщение-запроса, в виде, полученном оконечным сервером.
9.2.2. 201 Created (Создано)
Запрос исполнен и в результате создан новый ресурс. Вновь созданный ресурс может быть доступен через URI, присланный в объекте отклика, со значащей частью URL ресурса в поле заголовка Location. Исходный сервер должен создать ресурс до отправки статусного кода 201. Если операция не может быть выполнена немедленно, сервер вместо этого должен откликнуться статусным кодом 202 (Accepted).
9.2.3. 202 Accepted (Принято)
Запрос был принят для исполнения, но обработка запроса не завершена. Запрос может обрабатываться или нет, так как он был блокирован в процессе исполнения. Не существует механизма повторной посылки статусного кода для асинхронных операций вроде этой.
Целью отклика 202 является разрешить серверу принять запрос для некоторого другого процесса (возможно процесса, запускаемого раз в день), не требуя того, чтобы соединение агента пользователя с сервером сохранялось до завершения процесса. Объект, возвращаемый этим откликом должен включать в себя текущий статус запроса и указатель на статус-монитор или некоторую оценку того, когда пользователь может ожидать завершения реализации запроса.
9.2.4. 203 Non-Authoritative Information (Не надежная информация)
Присылаемая в ответ метаинформация в заголовке объекта не идентифицируется, как полученная от исходного сервера, ее следует скорее считать косвенной, полученной опосредовано. Например, включение местной аннотационной информации о ресурсе может иметь последствия для мета информации, известной исходному серверу. Использование данного кода отклика не является обязательным и целесообразно лишь в случае, когда отклик мог бы быть равен 200 (OK).
9.2.5. 204 No Content (Никакого содержимого)
Сервер исполнил запрос, но нет никакой новой информации для отсылки. Этот отклик первоначально предназначался для разрешения ввода, не вызывая изменения активного документа агента пользователя.
Отклик может включать новую метаинформацию в форме заголовков объектов, которая должна быть передана для документа, отображаемого агентом пользователя.
Отклик 204 не должен включать тела сообщения и всегда завершается пустой строкой после полей заголовка.
9.2.6. 205 Reset Content (Сброс содержимого)
Сервер исполнил запрос и агент пользователя должен вернуть документ к виду, который он имел в момент посылки запроса. Этот отклик первоначально предназначался для обеспечения ввода при выполнении пользователем операции, за которой следует очистка формы, в которую произведен ввод, так что пользователь может начать другую операцию ввода. Отклик не должен включать в себя объект.
9.2.7. 206 Partial Content (Частичное содержимое)
Сервер исполнил частично запрос GET для заданного ресурса. Запрос должен включать поле заголовка Range (раздел 13.36), указывающее на желательный интервал (range). Отклик должен включать поле заголовка Content-Range (раздел 13.17), указывающее диапазон данных, включенных в отклик, или множественные байтные интервалы (multipart/byteranges) Content-Type, включающие поля Content-Range для каждой из частей. Если множественные байтные интервалы не используются, поле заголовка Content-Length в отклике должно соответствовать действительному числу октетов в теле сообщения. Кэш, который не поддерживает заголовки Range и Content-Range, не должен кэшировать отклики 206 (Partial).
9.3. Redirection 3xx (Переадресация)
Этот класс статусных кодов указывает, что для выполнения запроса, нужны дальнейшие действия агента пользователя. Необходимые действия могут быть выполнены агентом пользователя без взаимодействия с пользователем, тогда и только тогда, когда используемый метод соответствует GET или HEAD. Агент пользователя не должен автоматически переадресовывать запрос более чем 5 раз, так как такая переадресация обычно свидетельствует о зацикливании запроса.
9.3.1. 300 Multiple Choices (Множественный выбор)
Запрошенный ресурс соответствует какому-то представлению из имеющегося набора представлений, каждое со своим адресом.
Имеется информация (раздел 11), полученная в результате согласования под управлением агента пользователя, так что пользователь (или агент пользователя) может выбрать предпочтительное представление и переадресовать свой запрос по соответствующему адресу.
Если это только не был запрос HEAD, отклик должен включать объект, содержащий список характеристик ресурсов и их адресов, из которых пользователь или агент пользователя может выбрать наиболее подходящий. Формат объекта специфицируется типом среды, заданным полем заголовка Content-Type. В зависимости от формата и возможностей агента пользователя, выбор наиболее подходящего варианта может быть выполнен автоматически. Однако, эта спецификация не определяет какого-либо стандарта для такого автоматического выбора.
Если сервер имеет предпочтительный вариант представления, ему следует включить соответствующий URL этого представления в поле Location. Агент пользователя может использовать значение поля Location для реализации автоматического выбора. Этот отклик может кэшироваться, если не указано обратного.
9.3.2. 301 Moved Permanently (Постоянно перемещен)
Запрошенному ресурсу был приписан новый постоянный URI и любая будущая ссылка на этот ресурс должна делаться с использованием одного из присланных URI. Клиенты с возможностью редактирования связей должны, где возможно, автоматически менять связи для ссылок Request-URI на одну или более новых ссылок, присланных сервером. Этот отклик можно кэшировать, если не указано обратного.
Если новый URI является адресом (location), его URL должен быть задан в поле Location отклика. Если метод запроса не HEAD, объект отклика должен содержать короткое гипертекстное замечание с гиперсвязью, указывающей на новый URI.
Если получен статусный код 301 в ответ на запрос, отличный от GET или HEAD, агент пользователя не должен автоматически переадресовывать запрос, если только это не может быть подтверждено пользователем, так как такая переадресация может изменить условия, при которых направлен запрос.
Замечание: При автоматической переадресации запроса POST, получив статусный код 301, некоторые существующие агенты пользователя HTTP/1.0 ошибочно меняют его на запрос GET.
9.3.3. 302 Moved Temporarily (Временно перемещен)
Запрошенный ресурс размещается временно под различными URI. Так как переадресация может быть случайно изменена, клиент должен продолжать использовать Request-URI для будущих запросов. Этот отклик допускает кэширование, если имеются соответствующие указания в полях заголовка Cache-Control или Expires.
Если новый URI является адресом (location), его URL должен задаваться полем Location отклика. Если запрошенный метод не HEAD, объект отклика должен содержать короткое гипертекстное замечание с гиперсвязью, указывающей на новый URI.
Если в ответ на запрос, отличный от GET или HEAD, получен статусный код 302, агент пользователя не должен автоматически переадресовывать запрос, если это не может быть подтверждено пользователем, так как это может изменить условия, при которых был выдан запрос.
Замечание: Когда после получения статусного кода 302 автоматически переадресуется запрос POST, некоторые существующие агенты пользователя HTTP/1.0 ошибочно меняют его на запрос GET.
9.3.4. 303 See Other (смотри другие)
Отклик на запрос может быть найден под разными URI. Его следует извлекать с помощью метода GET. Этот метод первоначально создан для того, чтобы позволить переадресацию агента пользователя на выбранный ресурс при запуске скрипта с помощью POST. Новый URI не является заменой ссылки для первоначально запрошенного ресурса. Отклик 303 не кэшируется, но отклик на второй (переадресованный) запрос может кэшироваться.
Если новый URI является адресом (location), его URL должно быть задано в поле Location отклика. Если метод запроса не HEAD, объект отклика должен содержать гипертекстовую ссылку на новый URI.
9.3.5. 304 Not Modified (Не модифицировано)
Если клиент выполнил условный запрос GET и получил доступ, а документ не был модифицирован, сервер должен реагировать этим статусным кодом.
Отклик не должен содержать тела сообщения.
Отклик должен включать поля заголовка:
Дата
ETag и/или Content-Location, если заголовок был послан в рамках отклика 200 на тот же самый запрос
Expires, Cache-Control и/или Vary, если значение поля может отличаться от посланного в каком-либо предыдущем отклике того же типа
Если условный GET использовал строгий валидатор кэша (см. раздел 12.8.3), отклик не должен содержать других заголовков объекта. В противном случае (напр., условный GET использовал слабый валидатор), отклик не должен включать в себя другие заголовки. Это предотвращает несогласованности между кэшированными телами объектов и актуализованными заголовками (updated headers).
Если отклик 304 указывает на то, что объект не кэширован, тогда кэш должен
игнорировать отклик и повторить запрос уже в безусловном режиме.
Если кэш использует полученный отклик 304 для актуализации записи в кэше, то кэш должен выполнить актуализацию с учетом новых значений полей, присланных в отклике.
Отклик 304 не должен включать в себя тело сообщения и, по этой причине всегда завершается пустой строкой после полей заголовка.
9.3.6. 305 Use Proxy (Используйте прокси)
Запрошенный ресурс должен иметь доступ через прокси-сервер, указанный в поле Location. Поле Location задает URL прокси-сервера. Предполагается, что получатель повторит запрос через прокси.
9.4. Client Error 4xx (Ошибка клиента)
Класс статус кодов 4xx предназначен для случаев, когда клиент допустил ошибку. За исключением случая отклика на запрос HEAD, серверу следует включить объект, содержащий объяснение ошибочной ситуации, а также указать, является ли ситуация временной или постоянной. Эти статусные коды применимы к любому методу запросов. Агенту пользователя следует отобразить все объекты.
Замечание. Если клиент посылает данные, реализация сервера, использующая протокол TCP, должна позаботиться о том, чтобы клиент получил пакет, содержащий отклик, до того как сервер закроет данное соединение. Если клиент продолжает посылку данных серверу после закрытия связи, TCP-уровень сервера должен послать клиенту пакет reset (сброс), который может стереть содержимое входного буфера клиента до того, как оно будет прочитано и интерпретировано приложением HTTP.
9.4.1. 400 Bad Request (Плохой запрос)
Запрос может быть не понят сервером из-за ошибочного синтаксиса. Клиенту не следует повторять запрос без модификации.
9.4.2. 401 Unauthorized (Не авторизован)
Запрос требует авторизации пользователя. Отклик должен включать в себя поле заголовка WWW-Authenticate (раздел 13.46), содержащее требование (challenge), применимое к запрошенному ресурсу. Клиент может повторить запрос с соответствующим содержимым поля заголовка Authorization (раздел 13.8). Если запрос уже включал допуск в поле Authorization, тогда отклик 401 указывает на то, что данный допуск не работает. Если отклик 401 содержит то же требование, что и предшествующий отклик, а агент пользователя уже пробовал пройти идентификацию по крайней мере хотя бы раз, тогда пользователю следует предоставить объект, содержащийся в отклике, так как он может содержать полезную диагностическую информацию. Идентификация доступа HTTP описана в разделе 10.
9.4.3. 402 Необходима оплата
Этот код зарезервирован для использования в будущем.
9.4.4. 403 Forbidden (Запрещено)
Сервер понял запрос, но отказался его исполнить. Авторизация не поможет и повторять запрос не следует. Если метод запроса не HEAD, а сервер желает открыто объявить причину неисполнения запроса, то ему следует описать соображения, по которым запрос отклонен Этот статусный код обычно используется, когда сервер не хочет показывать, почему запрос отклонен, или когда другой отклик не подходит.
9.4.5. 404 Not Found (Не найдено)
Сервер не нашел ничего, отвечающего Request-URI. Не приводится никаких данных о том, являются ли эта ситуация временной или постоянной.
Если сервер не хочет сделать эту информацию открытой для клиента, вместо этого может использоваться статусный код 403. Статусный код 410 (Gone - Утрачен) следует использовать, если сервер знает за счет некоторого внутреннего механизма конфигурации, что старый ресурс постоянно недоступен и не имеет нового адреса его размещения.
9.4.6. 405 Method Not Allowed (Метод не разрешен)
Метод, специфицированный в Request-Line, не разрешен для ресурса, указанного Request-URI. Отклик должен включать заголовок Allow, содержащий список разрешенных методов для запрошенного ресурса.
9.4.7. 406 Not Acceptable (Не приемлемо)
Ресурс, идентифицированный запросом, способен только генерировать объекты откликов, которые имеют характеристики, неприемлемые согласно заголовкам accept, присланным в запросе.
Если это не запрос HEAD, отклик должен включать объект, содержащий список доступных характеристик объекта и адреса, где пользователь или агент пользователя может выбрать нечто наиболее подходящее. Формат объекта специфицируется типом среды, приведенным в поле заголовка Content-Type. В зависимости от формата и возможностей агента пользователя, оптимальный выбор может быть сделан автоматически. Однако данная спецификация не определяет какого-либо стандарта для такого автоматического выбора.
Замечание. HTTP/1.1 серверам разрешено присылать отклики, которые неприемлемы согласно заголовкам accept, присланным в запросе. В некоторых случаях, может оказаться предпочтительнее послать отклик 406. Агенты пользователя могут просматривать заголовки приходящих откликов с тем, чтобы определить, являются ли они приемлемыми. Если отклик не может быть воспринят, агенту пользователя следует временно прервать прием данных и запросить пользователя принять решение о дальнейших действиях.
9.4.8. 407 Proxy Authentication Required (Необходима идентификация прокси)
Этот статусный код подобен 401 (Unauthorized), но указывает, что клиент должен сначала авторизоваться на прокси-сервере. Прокси должен прислать в ответ поле заголовка Proxy-Authenticate (раздел 13.33), содержащего требования, реализуемые на прокси для запрошенного ресурса. Клиент может повторить запрос с подходящим полем заголовка Proxy-Authorization (раздел 13.34). Авторизация доступа HTTP описана в разделе 10.
9.4.9. 408 Request Timeout (Таймаут запроса)
Клиент не выдал запрос в пределах временного интервала, в течение которого сервер его ожидал.
Клиент может повторить запрос без модификаций в любое время.
9.4.10. 409 Conflict (Конфликт)
Выполнение запроса не может быть завершено из-за конфликта с текущим состоянием ресурса. Этот статусный код разрешен в ситуациях, где предполагается, что пользователь может разрешить конфликт и повторно послать запрос. Тело отклика должно включать достаточно информации, чтобы пользователь мог понять причину конфликта. В идеале, объект отклика должен был бы включать достаточно информации для пользователя или агента пользователя для того, чтобы уладить конфликт, однако это невозможно и необязательно.
Конфликты наиболее вероятно происходят в результате запроса PUT. Если задействована версия и объект операции PUT вызывает изменение ресурса, которые конфликтуют с изменениями внесенными запросом, выполненным ранее, сервер может использовать отклик 409 для того, чтобы указать на невозможность завершить выполнение запроса. В этом случае объект отклика должен содержать список отличий между двумя версиями формата, определенном откликом Content-Type.
9.4.11. 410 Gone (Исчез)
Запрошенный ресурс не является более доступным на сервере и не известен указатель переадресации. Это условие следует считать постоянным. Клиенты с возможностями редактирования связей должны ликвидировать ссылки на Request-URI после подтверждения пользователем. Если сервер не знает или не имеет возможности определить, является ли данное условие постоянным или временным, следует использовать отклик со статусным кодом 404 (Not Found). Этот отклик можно кэшировать, если не указано обратного.
Отклик 410 первоначально предназначался для того, чтобы помочь работе задач в WWW-среде путем сообщения получателю о том, что ресурс заведомо недостижим и владелец сервера хотел бы, чтобы связи с этим ресурсом были удалены. Такое событие является типичным для ограниченного периода времени и для ресурсов, принадлежащих частным лицам, которые не работают более с данным сервером. Не обязательно отмечать все постоянно недоступные ресурсы, как исчезнувшие (Gone) или сохранять такую пометку произвольное время – это оставлено на усмотрение собственника сервера.
9.4.12. 411 Length Required (Необходима длина)
Сервер отказывается принять запрос без определенного значения Content-Length. Клиент может повторить запрос, если он добавит корректное значение поля заголовка Content-Length, содержащего длину тела сообщения.
9.4.13. 412 Precondition Failed (Предварительные условия не выполнены)
Предварительные условия, заданные в одном или более полях заголовка запроса, воспринимаются как не выполненные, когда это проверено сервером. Этот код отклика позволяет клиенту установить предварительные условия для метаинформации (данные поля заголовка) текущего ресурса и, таким образом, предотвратить возможность использования запрошенного метода для ресурса, отличного от указанного.
9.4.14. 413 Request Entity Too Large (Объект запроса слишком велик)
Сервер отказывается обрабатывать запрос, потому что объект запроса больше, чем сервер способен обработать. Сервер может закрыть соединение, чтобы помешать клиенту продолжать посылать запросы.
Если условие является временным, серверу следует включить поле заголовка Retry-After, чтобы указать на временность этого условия, что означает возможность повторения запроса некоторое время спустя.
9.4.15. 414 Request-URI Too Long (URI запроса слишком велик)
Сервер отказывается обслужить запрос, потому что Request-URI длиннее, чем сервер способен интерпретировать. Это редкое обстоятельство может возникнуть только, когда клиент не корректно преобразует запрос POST в GET с длинной информацией запроса. При этом клиент ныряет в "черную дыру" переадресаций. Примером может служить преадресованный URL префикс, который указывает на свой суффикс, или случай атаки сервера клиентом, который пытается использовать дыры в системе безопасности, имеющиеся у клиентов с фиксированной емкостью буферов для работы с Request-URI.
9.4.16. 415 Unsupported Media Type (Неподдерживаемый тип среды)
Сервер отказывается обслужить запрос, потому что объект запроса имеет формат, неподдерживаемый запрашиваемым ресурсом для указанного метода.
9.5. Сервер ошибок 5xx
Статусный код отклика, начинающийся с цифры "5", указывает на случаи, когда сервер опасается, что он ошибся или не может реализовать запрос. За исключением случаев, когда обрабатывается запрос HEAD, серверу следует включить объект, содержащий объяснение создавшейся ошибочной ситуации и указывающей на то, является ли ситуация временной или постоянной. Агенту пользователя следует отобразить пользователю любой объект, включенный в отклик. Эти коды откликов применимы для любых методов запроса.
9.5.1. 500 Internal Server Error (Внутренняя ошибка сервера)
Сервер столкнулся с непредвиденными условиями, которые мешают ему исполнить запрос.
9.5.2. 501 Not Implemented (Не применимо)
Сервер не поддерживает функцию, которая должна быть реализована в ходе исполнения запроса. Это адекватный отклик, когда сервер не распознает метод запроса и не способен поддерживать его для данного ресурса.
9.5.3. 502 Bad Gateway (Плохой шлюз)
Сервер при работе в качестве шлюза или прокси получил неверный отклик от вышестоящего сервера, к которому он обратился, выполняя запрос.
9.5.4. 503 Service Unavailable (Услуга не доступна)
Сервер в данный момент не может обработать запрос в связи с временной перегрузкой или другими сложившимися обстоятельствами.
Замечание. Существование статусного кода 503 не предполагает, что сервер должен использовать его, когда оказывается перегруженным. Некоторые серверы могут захотеть просто отказаться устанавливать соединение.
9.5.5. 504 Gateway Timeout (Таймаут шлюза)
Сервер при работе в качестве внешнего шлюза или прокси-сервера не получил своевременно отклик от вышестоящего сервера, к которому он обратился, пытаясь исполнить запрос.
9.5.6. 505 HTTP Version Not Supported (Версия не поддерживается)
Сервер не поддерживает или отказывается поддерживать версию протокола HTTP, которая была использована в сообщении-запросе. Сервер индицирует, что он не способен или не хочет завершать обработку запроса в рамках главной версии клиента, как это описано в разделе 2.1, в отличие от сообщения об ошибке.
Отклику следует содержать объект, описывающий, почему эта версия не поддерживается и какие другие протоколы поддерживаются сервером.
4.5.6.1.10. Идентификация доступа
HTTP предлагает простой механизм аутентификации с помощью отклика, который может использоваться сервером, чтобы потребовать от клиента прислать запрос, содержащий аутентификационную информацию. Для определения схемы идентификации он использует лексему произвольной длины, не зависящую от применения строчных или прописных символов, за ней следует список пар атрибут-значение. Элементы списка отделяются друг от друга запятыми. Атрибуты представляют собой параметры, которые определяют аутентификацию в рамках выбранной схемы.
| Auth-scheme | = token |
| auth-param | = token "=" quoted-string |
| Challenge | = auth-scheme 1*SP realm *( "," auth-param ) |
| Realm | = "realm" "=" realm-value |
| realm-value | = quoted-string |
Агент пользователя, который хочет идентифицировать себя на сервере, после получения отклика 401 или 411 может сделать это, включив в запрос поле заголовка Authorization.
Значение поля Authorization состоит из записей, содержащих идентификационную информацию агента пользователя для области (realm) запрошенного ресурса.
credentials = basic-credentials
| auth-scheme #auth-param
Домен, в пределах которого может автоматически использоваться идентификационная информация, определяется зоной защиты. Если предыдущий запрос был авторизован, та же идентификационная информация может быть использована для всех других запросов в пределах зоны защиты и во временных рамках, заданных схемой идентификации, параметрами и/или предпочтениями пользователя. Если не определено обратного схемой авторизации, одна зона защиты не может быть распространена за пределы ее сервера.
Если сервер не хочет принимать идентификационную информацию, присланную в запросе, он должен прислать отклик 401 (Unauthorized). Отклик должен включать поле заголовка WWW-Authenticate, содержащее требование (возможно новое), применимое для запрошенного ресурса, и объект, объясняющий причину отказа.
Протокол HTTP не ограничивает приложения только этим простым механизмом авторизации (требование-отклик). Может быть применен дополнительный механизм, такой как шифрование на транспортном уровне или использование инкапсуляции сообщений. Однако в данной спецификации эти дополнительные механизмы не определены.
Прокси-серверы должны быть полностью прозрачны по отношению авторизации агентов пользователя. То есть, они должны переадресовывать в неприкосновенном виде заголовки WWW-Authenticate и Authorization, согласно правилам описанным в разделе 13.8.
HTTP/1.1 позволяет клиенту передать идентификационную информацию в прокси и обратно с использованием заголовков Proxy-Authenticate и Proxy-Authorization.
10.1 Базовая схема идентификации (Authentication)
Базовая схема авторизации базируется на модели, в которой агент пользователя должен идентифицировать себя с помощью имени пользователя и пароля, необходимого для каждой области (realm). Значение атрибута realm должно рассматриваться в виде неотображаемой строки символов, которая может сравниваться с другим значение realm на этом сервере.
Сервер обслужит запрос только в случае, если убедится в корректности имени и пароля пользователя для данной зоны защиты Request-URI. Не существует каких-либо опционных параметров авторизации.
При получении неавторизованного запроса для URI в пределах зоны защиты (protection space), сервер может реагировать посылкой требования в виде:
WWW-Authenticate: Basic realm="WallyWorld"
где "WallyWorld" – строка присвоенная сервером для идентификации зоны защиты Request-URI.
Чтобы получить авторизацию клиент посылает свое имя и пароль, разделенные символом двоеточие (":"), и закодированные согласно base64.
basic-credentials = "Basic" SP basic-cookie
basic-cookie =
user-pass = userid ":" password
userid = *
password = *TEXT
Идентификационная информация может быть чувствительной к применению строчных или прописных букв.
Если агент пользователя хочет послать имя пользователя "Aladdin" и пароль "Сезам открой", он использует следующее поле заголовка:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Смотри раздел 14 по поводу соображений безопасности, связанных с базовой авторизацией.
10.2 Краткое изложение схемы авторизации
Краткое изложение идей авторизации для HTTP представлено в документе RFC-2069 [32].
4.5.6.1.11. Согласование содержимого
Большинство HTTP откликов включают в себя объекты, которые содержат информацию для интерпретации человеком-пользователем. Естественно, желательно обеспечить пользователя наилучшим объектом, соответствующим запросу. К сожалению для серверов и кэшей не все пользователи имеют одни и те же предпочтения и не все агенты пользователя в равной степени способны обрабатывать все типы объектов. По этой причине, HTTP имеет несколько механизмов обеспечения согласования содержимого – процесс выбора наилучшего представления для данного отклика, когда доступны несколько возможностей.
Замечание. Это не называется "согласование формата " потому, что альтернативные представления могут принадлежать к одному и тому же типу среды, но использовать различные возможности этого типа, например, различные иностранные языки.
Любой отклик, содержащий тело объекта может быть предметом согласования, включая отклики об ошибках. Существует два вида согласования содержимого, которые возможны в HTTP: согласование под управлением сервера и под управлением агента пользователя. Эти два сорта согласования могут использоваться по отдельности или в сочетании. Один из методов, называемый прозрачным согласованием, реализуется, когда кэш использует информацию, полученную от исходного сервера в результате согласования под управлением агента пользователя. Эта информация используется для последующих запросов, где осуществляется согласование под управлением сервера.
11.1 Согласование, управляемое сервером
Если выбор наилучшего представления для отклика выполнен с использованием некоторого алгоритма на сервере, такая процедура называется согласованием под управлением сервера. Выбор базируется на доступных представлениях отклика (размеры, в пределах которых он может варьироваться, язык, кодировка и т.д.) и на содержимом конкретных полей заголовка в сообщении-запросе или другой информации, имеющей отношение к запросу (например, сетевой адрес клиента).
Согласование, управляемое сервером предпочтительнее, когда алгоритм выбора из числа доступных представлений трудно описать агенту пользователя. Согласование под управлением сервера привлекательно тогда, когда сервер хочет послать свои “наилучшие предложения” клиенту вместе с первым откликом (надеясь избежать задержек RTT последующих запросов, если предложение удовлетворит пользователя). Для того чтобы улучшить предложения сервера, агент пользователя может включить в запрос поля заголовка (Accept, Accept-Language, Accept-Encoding, и т.д.), которые описывают его предпочтения для данного запроса. Согласование под управлением сервера имеет следующие недостатки:
Для сервера трудно определить, что является ”лучшим” для любого заданного пользователя, так как это потребовало бы полного знания как возможностей агента пользователя, так конкретного назначения отклика (напр., хочет ли пользователь видеть отклик на экране или отпечатать на принтере?).
Заставлять агента пользователя описывать свои возможности при каждом запросе крайне неэффективно (ведь лишь небольшой процент запросов имеют несколько вариантов представления) и потенциально нарушает конфиденциальность пользователя.
Это усложняет реализацию исходного сервера и алгоритм генерации откликов на запросы.
Это может ограничить возможность общедоступного кэша использовать один и тот же отклик для запросов многих пользователей.
HTTP/1.1 включает в себя следующие поля заголовка запроса для активации согласования, управляемого сервером, через описание возможностей агента пользователя и предпочтений самого пользователя: Accept (раздел 13.1), Accept- Charset (раздел 13.2), Accept-Encoding (раздел 13.3), Accept-Language (раздел 13.4) и User-Agent (раздел 13.42). Однако, исходный сервер не ограничен этими рамками и может варьировать отклик, основываясь на свойствах запроса, включая информацию помимо полей заголовка запроса или используя расширения полей заголовка нерассмотренные в данной спецификации.
Исходные серверы HTTP/1.1 должны включать соответствующие, управляемом сервером. Поле Vary описывает пределы, в которых может варьироваться отклик (то есть, пределы, в которых исходный сервер выбирает свои “наилучшие предложения” отклика из многообразия редставлений).
HTTP/1.1 общедоступный кэш должен распознавать поле заголовка Vary, когда оно включено в отклик и подчиняется требованиям, описанным в разделе 12.6, где рассматриваются взаимодействия между кэшированием и согласованием содержимого.
11.2. Согласование, управляемое агентом (Agent-driven Negotiation)
При согласовании, управляемом агентом, выбор наилучшего представления для отклика выполняется агентом пользователя после получения стартового отклика от исходного сервера. Выбор базируется на списке имеющихся представлений отклика, включенном в поля заголовка (эта спецификация резервирует имя поля Alternates, как это описано в приложении 16.6.2.1,) или в тело объекта исходного отклика, при этом каждое представление идентифицируется своим собственным URI.
Выбор из числа представлений может быть выполнен автоматически (если агент пользователя способен на это) или вручную пользователем, выбирая вариант из гипертекстного меню.
Согласование, управляемое агентом, имеет преимущество тогда, когда отклик варьируется в определенных пределах (таких как тип, язык или кодирование), когда исходный сервер не способен определить возможности агента пользователя, проанализировав запрос, и вообще, когда общедоступные кэши используются для распределения нагрузки серверов и для снижения сетевого трафика.
Согласование под управлением агента имеет тот недостаток, что требуется второй запрос для получения наилучшего альтернативного представления. Этот второй запрос эффективен только тогда, когда используется кэширование. Кроме того, эта спецификация не определяет какого-либо механизма поддержки автоматического выбора, хотя она и не препятствует применению любого такого механизма в рамках расширения HTTP/1.1.
HTTP/1.1 определяет статусные коды 300 (Multiple Choices – множественный выбор) и 406 (Not Acceptable – Не приемлем) для активации согласования под управлением агента, когда сервер не хочет или не может обеспечить свой механизм согласования.
11.3 Прозрачное согласование (Transparent Negotiation)
Прозрачное согласование представляет собой комбинацию управления сервера и агента. Когда кэш получает форму списка возможных представлений откликов (как в согласовании под управлением агента) и кэшу полностью поняты пределы вариации, тогда кэш становится способным выполнить согласование под управлением сервера для исходного сервера при последующих запросах этого ресурса.
Прозрачное согласование имеет преимущество распределения работы согласования, которое в противном случае было бы выполнено исходным сервером. При этом удаляется также задержка, сопряженная со вторым запросом при схеме согласования под управлением агента, когда кэш способен правильно прогнозировать отклик.
Эта спецификация не определяет какого-либо механизма для прозрачного согласования, хотя она и не препятствует использованию таких механизмов в будущих версиях HTTP/1.1.
Выполнение прозрачного согласования кэшем HTTP/1.1 должно включать в отклик поле заголовка Vary (определяя пределы его вариаций), обеспечивая корректную работу со всеми клиентами HTTP/1.1.
4.5.6.1.12 Кэширование в HTTP
HTTP обычно используется для распределенных информационных систем, где эксплуатационные характеристики могут быть улучшены за счет применения кэширования откликов. Протокол HTTP/1.1 включает в себя много элементов, предназначенных для оптимизации такого кэширования. Благодаря тому, что эти элементы завязаны с другими аспектами протокола и из-за их взаимодействия друг с другом, полезно описать базовую схему кэширования в HTTP отдельно от детального рассмотрения методов, заголовков, кодов откликов и т.д.
Кэширование представляется бесполезным, если оно значительно не улучшит работу. Целью кэширования в HTTP/1.1 является исключение во многих случаях необходимости посылать запросы, а в некоторых других случаях - полные отклики. При этом уменьшается число необходимых RTT для многих операций. Для этих целей используется механизм “истечения срока” (expiration) (см. раздел 12.2). Одновременно снижаются требования к полосе пропускания сети, для чего применяется механизм проверки пригодности (см. раздел 12.3).
Требования к рабочим характеристикам, доступности и работе без соединения заставляют нас несколько снизить семантическую прозрачность. Протокол HTTP/1.1 позволяет исходным серверам, кэшам и клиентам снизить прозрачность, когда необходимо. Так как непрозрачность операций может поставить в тупик недостаточно опытных пользователей, а также привести к определенной несовместимости для некоторых серверных приложений (таких как торговля по заказу), протокол рекомендует не убирать прозрачность полностью, а лишь несколько ослабить.
Следовательно, протокол HTTP/1.1 обеспечивает следующие важные моменты:
Протокольные особенности, которые гарантируют полную семантическую прозрачность, когда это требуется всеми участниками процесса. Протокольные особенности, которые позволяют исходному серверу или агенту пользователя запросить и управлять непрозрачными операциями. Протокольные особенности, которые позволяют кэшу присоединить предупреждения к откликам, которые не сохраняют запрошенный уровень семантической прозрачности.
Базовым принципом является возможность для клиентов детектировать любое ослабление семантической прозрачности.
Замечание. Разработчики серверов, кэшей или клиентов могут столкнуться с решениями, которые не обсуждались в данной спецификации. Если решение может повлиять на семантическую прозрачность, разработчик может ошибаться относительно прозрачной работы, не проведя детального анализа и не убедившись, что нарушение такой прозрачности дает существенные преимущества.
12.1 Корректность кэша
Корректный кэш должен реагировать на запрос откликом новейшей версии, которой он владеет. Разумеется, отклик должен соответствовать запросу (см. разделы 12.5, 12.6, и 12.12) и отвечать одному из следующих условий:
Он был проверен на эквивалентность с тем, который бы прислал исходный сервер при соответствующем запросе (раздел 12.3); Он достаточно нов (см. раздел 12.2). В варианте по умолчанию это означает, что он отвечает минимальным требованиям клиента, сервера и кэша по новизне (см. раздел 13.9). Если исходный сервер задает такие требования, то это только его требования на новизну.
Он включает в себя предупреждение, о нарушении требований новизны клиента или исходного сервера (см. разделы 12.5 и 13.45).
Это сообщение-отклик 304 (Not Modified), 305 (Proxy Redirect), или ошибка (4xx или 5xx).
Если кэш не может осуществлять обмен с исходным сервером, он должен реагировать в соответствии с вышеприведенными правилами, если отклик может быть корректно обслужен, в противном случае он должен отослать сигнал ошибки или предупреждения, указывающий, что имел место отказ в системе коммуникаций.
Если кэш получает отклик (полный отклик или код 304 (Not Modified)), который уже не является свежим, кэш должен переадресовать его запросившему клиенту без добавления нового предупреждения, и не удаляя существующего заголовка Warning. Кэшу не следует пытаться перепроверить отклик, так как это может привести к бесконечному зацикливанию. Агент пользователя, который получает устаревший отклик без Warning, может отобразить предупреждение для пользователя.
12.2 Предупреждения
Когда кэш присылает опосредованный отклик, который “недостаточно свеж” (с точки зрения условия 2 раздела 12.1), к нему должно быть присоединено предупреждение об этом с использованием заголовка Warning. Это предупреждение позволяет клиентам предпринять соответствующие действия.
Предупреждения могут использоваться для других целей, как кэшами так и другими системами. Использование предупреждения, а не статусного кода ошибки, отличает эти отклики от действительных отказов в системе.
Предупреждения всегда допускают кэширование, так как они никогда не ослабляют прозрачности отклика. Это означает, что предупреждения могут передаваться HTTP/1.0 кэшам без опасения, что такие кэши просто передадут их как заголовки объектов отклика.
Предупреждениям приписаны номера в интервале от 0 до 99. Данная спецификация определяет номера кодов и их значения для каждого из предупреждений, позволяя клиенту или кэшу обеспечить во многих случаях (но не во всех) автоматическую обработку ситуаций.
Предупреждения несут в себе помимо кода и текст. Текст может быть написан на любом из естественных языков (предположительно базирующемся на заголовках Accept клиента) и включать в себя опционное указание того, какой набор символов используется.
К отклику может быть присоединено несколько предупреждений (исходным сервером или кэшем), включая несколько предупреждений с идентичным кодом. Например, сервер может выдать одно и то же предупреждение на английском и мордовском.
Когда к отклику присоединено несколько предупреждений, не будет практичным и разумным отображать их все на экране для пользователя. Эта версия HTTP не специфицирует строгих правил приоритета для принятия решения, какие предупреждения отображать и в каком порядке, но предлагает некоторые эвристические соображения.
Заголовок Warning и определенные в настоящий момент предупреждения описаны в разделе 13.45.
12.3 Механизмы управления кэшем
Базовым механизмом кэша в HTTP/1.1 (времена таймаутов и валидаторы) являются неявные директивы кэша.
В некоторых случаях серверу или клиенту может потребоваться выдать прямую директиву кэшу. Для этих целей используется заголовок Cache-Control.
Заголовок Cache-Control позволяет клиенту или серверу передать большое число директив через запросы или отклики. Эти директивы переписывают указания, которые действуют по умолчанию при реализации алгоритма работы кэша. Если возникает явный конфликт между значениями заголовков, то используется наиболее регламентирующее требование (то есть, то, которое наиболее вероятно сохраняет прозрачность семантики).
Однако в некоторых случаях директивы Cache-Control сформулированы так, что явно ослабляют семантическую прозрачность (например, "max-stale" или "public"). Директивы Cache-Control подробно описаны в разделе 13.9.
12.4 Прямые предупреждения агента пользователя
Многие агенты пользователя позволяют переписывать базовый механизм кэширования. Например, агент пользователя может специфицировать то, какие кэшированные объекты (даже явно старые) не проверять на новизну. Или агент пользователя может всегда добавлять "Cache-Control: max-stale=3600" к каждому запросу.
Если пользователь переписал базовый механизм кэширования, агент пользователя должен явно указать всякий раз, когда это важно, что отображаемая информация не отвечает требованиям прозрачности (в частности, если отображаемый объект известен как устаревший). Так как протокол обычно разрешает агенту пользователя определять, является ли отклик устаревшим, такая индикация нужна только тогда, когда это действительно случится. Для такой индикации не нужно диалоговое окно; это может быть иконка (например, изображение гнилой рыбы) или какой-то иной визуальный индикатор.
Если пользователь переписал механизм кэширования таким образом, что он непомерно понизил эффективность кэша, агент пользователя должен непрерывно отображать индикацию (например, изображение горящих денег), так чтобы пользователь, беспечно расходующий ресурсы, страдал от заметной задержки откликов на его действия.
12.5 Исключения для правил и предупреждений
В некоторых случаях оператор кэша может выбрать такую конфигурацию, которая возвращает устаревшие отклики, даже если клиенты этого не запрашивали. Это решение не должно приниматься легко, но может быть необходимо по причинам доступности или эффективности, особенно когда кэш имеет плохую связь с исходным сервером. Всякий раз, когда кэш возвращает устаревший отклик, он должен пометить его соответствующим образом (используя заголовок Warning). Это позволяет клиентскому программному обеспечению предупредить пользователя о возможных проблемах.
Такой подход позволяет также агенту пользователя предпринять шаги для получения “свежего” отклика или информации из первых рук. По этой причине кэшу не следует присылать устаревшие отклики, если клиент запрашивает информацию из первых рук, если только невозможно это сделать по техническим или политическим причинам.
12.6 Работа под управлением клиента
Когда основным источником устаревшей информации является исходный сервер (и в меньшей мере промежуточные кэши), клиенту может быть нужно контролировать решение кэша о том, следует ли присылать кэшированный отклик без его проверки. Клиенты выполняют это, используя несколько директив заголовка Cache-Control.
Запрос клиента может специфицировать максимальный возраст, который он считает приемлемым для не верифицированного отклика. Клиент может также специфицировать минимальное время, в течение которого отклик еще считается пригодным для использования. Обе эти опции увеличивают ограничения, накладываемые на работу кэша.
Клиент может также специфицировать то, что он будет воспринимать устаревшие отклики с возрастом не более заданного. Это ослабляет ограничения, налагаемые на работу кэшей и, таким образом, может привести к нарушению семантической прозрачности, заданной исходным сервером, хотя это может быть необходимо для поддержания автономной работы кэша в условиях плохой коннективности.
12.7. Модель истечения срока годности
12.7.1 Определение срока годности под управлением сервера
Кэширование в HTTP работает наилучшим образом, когда кэши могут полностью исключить запросы к исходному серверу. Другими словами, кэш должен возвращать “свежий” отклик без обращения к серверу.
Предполагается, что серверы припишут в явном виде значения времени пригодности (expiration time) откликам в предположении, что объекты вряд ли изменятся семантически значимым образом до истечения этого времени. Это сохраняет семантическую прозрачность при условии, что время жизни выбрано корректно.
Механизм времени пригодности (expiration) применим только к откликам, взятым из кэша, а не к откликам, полученным из первых рук и переадресованных запрашивающему клиенту.
Если исходный сервер хочет усилить семантическую прозрачность кэша, тогда он может установить время истечения действия в прошлое, чтобы проверялся каждый запрос. Это означает, что всякий запрос изначально будет считаться устаревшим, и кэш будет вынужден проверить его прежде чем использовать для последующих запросов. О более жестких методах вынуждения проверки действенности отклика смотри раздел 13.9.4.
Если исходный сервер хочет заставить любой HTTP/1.1 кэш, вне зависимости от его конфигурации проверять каждый запрос, он может использовать директиву Cache-Control "must-revalidate” (см. раздел 13.9).
Серверы определяют реальные времена сроков пригодности, используя заголовок Expires, или директиву максимального возраста заголовка Cache-Control.
Время пригодности (expiration time) не может использоваться для того, чтобы заставить агента пользователя обновить картинку на дисплее или перезагрузить ресурс; его семантика применима только для механизма кэширования, а такой механизм нуждается только в контроле истечения времени жизни ресурса, когда инициируется новый запрос доступа к этому ресурсу.
12.7.2 Эвристический контроль пригодности
Так как исходные сервера не всегда предоставляют значение времени пригодности в явном виде, HTTP кэши присваивают им значения эвристически, используя алгоритмы, которые привлекают для оценки вероятного значения времени пригодности другие заголовки (такие как Last-Modified time).
Спецификация HTTP/1.1 не предлагает каких- либо специальных алгоритмов, но налагает предельные ограничения на полученный результат. Так как эвристические значения времени жизни могут подвергнуть риску семантическую прозрачность, они должны использоваться с осторожностью. Предпочтительнее, чтобы исходные серверы задавали время пригодности явно.
12.7.3. Вычисление возраста
Для того чтобы узнать является ли запись в кэш свежей, кэшу нужно знать превышает ли его возраст предельное время жизни. То, как вычислить время пригодности, обсуждается в разделе 12.7.4. Этот раздел описывает метод вычисления возраста отклика или записи в кэше.
В этом обсуждении используется термин “сейчас” для обозначения “текущего показания часов на ЭВМ, выполняющей вычисление". ЭВМ, которая использует HTTP, и в особенности ЭВМ, работающие в качестве исходных серверов и кэшей, должны использовать NTP [28] или некоторый схожий протокол для синхронизации их часов с использованием общего точного временного стандарта.
Следует обратить внимание на то, что HTTP/1.1 требует от исходного сервера посылки в каждом отклике заголовка Date, сообщая время, когда был сгенерирован отклик. Мы используем термин "date_value" для обозначения значения заголовка Date, в форме, приемлемой для арифметических операций.
HTTP/1.1 использует заголовок отклика Age для того, чтобы облегчить передачу информации о возрасте объектов между кэшами. Значение заголовка Age равно оценке отправителя времени, прошедшего с момента генерации отклика исходным сервером. В случае кэшированного отклика, который был перепроверен исходным сервером, значение Age базируется на времени перепроверки, а не на времени жизни оригинального отклика.
По существу значение Age равно сумме времени, в течение которого отклик был резидентен в каждом из кэшей вдоль пути от исходного сервера, плюс время распространения данных по сети.
Мы используем термин "age_value" для значения поля заголовка Age, в удобном для выполнения арифметических операций формате.
Возраст отклика может быть вычислен двумя совершенно независимыми способами.
Текущее время минус date_value, если местные часы синхронизованы с часами исходного сервера. Если результат отрицателен, он заменяется на нуль.
age_value, если все кэши вдоль пути отклика поддерживают HTTP/1.1.
Таким образом, мы имеем два независимых способа вычисления возраста отклика при его получении, допускается их комбинирование, например:
corrected_received_age = max(now - date_value, age_value)
и, поскольку мы имеем синхронизованные часы, или все узлы вдоль пути поддерживают HTTP/1.1, получается надежный (консервативный) результат.
Заметьте, что поправка применяется в каждом кэше HTTP/1.1 вдоль пути так, что, если встретится на пути кэш HTTP/1.0, правильное значение возраста будет получено потому, что его часы почти синхронизованы. Нам не нужна сквозная синхронизация (хотя ее не плохо бы иметь).
Из-за задержек, вносимых сетью, значительное время может пройти с момента генерации отклика сервером и получением его следующим кэшем или клиентом. Если не внести поправки на эту задержку, можно получить неправдоподобные значения возраста отклика.
Так как запрос, который определяет возвращаемое значение Age, должен быть инициирован до генерации этого значения Age, мы можем сделать поправку на задержки, вносимые сетью путем записи времени, когда послан запрос. Затем, когда получено значение Age, оно должно интерпретироваться относительно времени посылки запроса, а не времени когда был получен отклик. Этот алгоритм выдает результат, который не зависит от величины сетевой задержки. Таким образом, вычисляется:
corrected_initial_age = corrected_received_age + (now - request_time)
где "request_time" равно времени (согласно местным часам), когда был послан запрос, вызвавший данный отклик.
Резюме алгоритма вычисления возраста при получении отклика кэшем:
/*
* age_value
| * | равно значению Age: заголовок, полученный кэшем с этим откликом. |
| * | равно значению Date исходного сервера: заголовок |
/p> * request_time
| * | равно местному времени, когда кэш сделал запрос, который явился причиной этого кэшированного отклика |
| * | равно местному времени, когда кэш получил отклик |
| * | равно текущему (местному) времени |
apparent_age = max(0, response_time - date_value);
corrected_received_age = max(apparent_age, age_value);
response_delay = response_time - request_time;
corrected_initial_age = corrected_received_age + response_delay;
resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;
Когда кэш посылает отклик, он должен добавить к corrected_initial_age время, в течение которого отклик оставался резидентно локальным. Он должен ретранслировать этот полный возраст, используя заголовок Age, следующему кэшу-получателю.
Заметьте, что клиент не может надежно сказать, что отклик получен из первых рук, но присутствие заголовка Age определенно указывает на то, что это не так. Кроме того, если значение в отклике соответствует более раннему времени, чем местное время запроса клиента, отклик, вероятно, получен не из первых рук (в отсутствие серьезного сбоя часов).
12.4 Вычисление времени жизни (Expiration)
Для того, чтобы решить, является ли отклик свежим или устаревшим, нам нужно сравнить его время жизни с возрастом. Возраст вычисляется так, как это описано в разделе 12.3. Этот раздел описывает то, как вычисляется время жизни, и как определяется, истекло ли время жизни отклика. В обсуждении, приведенном ниже, величины могут быть представлены в любой форме, удобной для выполнения арифметических операций.
Мы используем термин "expires_value" для обозначения содержимого заголовка Expires. Для обозначения числа секунд, определенного директивой максимального возраста заголовка Cache-Control отклика (см. раздел 13.9), используется термин "max_age_value".
Директива максимального возраста имеет приоритет перед Expires, так если max-age присутствует в отклике, вычисление производится просто:
freshness_lifetime = max_age_value
В противном случае, если в отклике присутствует Expires, то вычисления осуществляются следующим образом:
freshness_lifetime = expires_value - date_value
Заметьте, ни одно из этих вычислений не зависит от синхронизации и корректной работы местных часов, так как вся исходная информация получается от исходного сервера.
Если ни Expires, ни Cache-Control: max-age не определяют максимальный возраст отклика, а отклик не содержит других ограничений на кэширование, кэш может вычислить время жизни, используя эвристику. Если эта величина больше 24 часов, кэш должен присоединить к отклику Warning 13, если такое предупреждение еще не добавлено.
Кроме того, если отклик имеет время Last-Modified, эвристическое значение времени жизни должно быть не больше некоторой доли времени, прошедшего со времени модификации. Типичное значение этой доли может составлять 10%.
Расчет того, истекло ли время жизни отклика, достаточно прост:
response_is_fresh = (freshness_lifetime > current_age)
12.5 Устранение неопределенности значений времени жизни
Из-за того, что значения времени жизни часто назначаются оптимистически, может так случиться, что два кэша содержат две “свежих” записи одного и того же ресурса, которые различаются.
Если клиент, выполняя извлечение ресурса, получает отклик не из первых рук на запрос, который был свежим в своем собственном кэше, а заголовок Date в его кэше новей, чем Date нового отклика, тогда клиент может игнорировать этот отклик. Если это так, он может
повторить запрос с директивой "Cache-Control: max-age=0" (см. раздел 13.9), чтобы усилить контроль со стороны исходного сервера.
Если кэш имеет два свежих отклика для одного и того же представления с различными указателями корректности (validator), он должен использовать тот, который имеет современный заголовок Date. Эта ситуация может возникнуть, когда кэш извлекает отклик из других кэшей, или потому, что клиент запросил перезагрузку или повторную проверку корректности заведомо свежего объекта.
12.6 Неопределенность из-за множественных откликов
Из- за того, что клиент может получать отклики по большому числу различных маршрутов, так что некоторые отклики проходят через одну последовательность кэшей, а другие, через другую, клиент может получить их не в той последовательности в какой они были посланы исходным сервером. Хотелось бы, чтобы клиент использовал наиболее свежие оклики, даже если срок годности старых еще не истек.
Ни метка объекта, ни значение времени жизни не могут определять порядок откликов, так как возможно, что более поздний отклик имеет срок годности, который истекает раньше. Однако, спецификация HTTP/1.1 требует передачи заголовка Date в каждом отклике, а значения Date должны быть кратны одной секунде.
Когда клиент пытается перепроверить запись в кэше, а отклик, который он получает, содержит заголовок Date, который оказывается старше, чем у другой уже существующей записи, тогда клиенту следует безусловно повторить запрос и включить
Cache-Control: max-age=0
Чтобы заставить некоторые промежуточные кэши сверить свои копии непосредственно с исходным сервером, или
Cache-Control: no-cache
Чтобы заставить любые промежуточные кэши получит новые копии от исходного сервера.
Если значения Date равны, тогда клиент может использовать любой отклик (или может, если он особенно осторожен, затребовать новый отклик). Серверы не должны зависеть от возможности клиентов четкого выбора между откликами, сгенерированными в пределах одной и той же секунды, если их сроки пригодности перекрываются.
12.8 Модель проверки пригодности
Когда кэш имеет устаревшую запись, которую бы он хотел использовать в качестве отклика на запрос клиента, он сначала должен произвести сверку с базовым сервером (или возможно промежуточным кэшем, содержащим свежий отклик), чтобы убедиться, что кэшированная запись все еще применима. Мы это называем проверкой пригодности записи кэша ("validating"). Так как мы не хотим пересылки всей записи, если с ней все в порядке, и мы не хотим тратить лишнее время из-за RTT в случае, если запись более не пригодна, протокол HTTP/1.1 поддерживает использование условных методов.
Ключевой особенностью протокола для поддержки условных методов являются так называемые “валидаторы” кэша. Когда исходный сервер генерирует полный отклик, он подключает к нему некоторые виды валидаторов, которые хранятся вместе с самой записью в кэше. Когда клиент (агент пользователя или прокси-кэш) выполняет условный запрос ресурса, для которого он имеет запись в кэше, он добавляет соответствующий валидатор к запросу.
Сервер сверяет полученный валидатор с текущим валидатором объекта и, если они совпадают, посылается отклик с соответствующим статусным кодом (обычно, 304 (Not Modified)) и без тела объекта. В противном случае он возвращает полный отклик (включая тело объекта). Таким образом, мы избегаем передачи полного отклика, если валидаторы взаимно согласованы.
Замечание. Функции сравнения, используемые при решении, согласуются ли между собой валидаторы, определены в разделе 12.8.3.
В HTTP/1.1 условный запрос выглядит точно также как и обычный запрос того же самого ресурса, за исключением того, что он несет в себе специальный заголовок (который содержит валидатор), и неявно меняет метод (обычный GET) на условный.
Протокол предусматривает как положительное, так и отрицательное значения условий проверки пригодности записей кэша. То есть, можно запросить, чтобы был реализован этот метод тогда и только тогда, когда валидатор подходит, или тогда и только тогда, когда ни один валидатор не подходит.
Замечание. Отклик, который не имеет валидатора, может кэшироваться и использоваться до истечения его срока годности, если только это явно не запрещено директивой Cache-Control. Однако, кэш не может выполнить условную доставку ресурса, если он не имеет валидатора для запрашиваемого объекта, что означает отсутствие возможности его актуализации после истечения срока годности.
12.8.1 Даты последней модификации
Значение поля заголовка объекта Last-Modified часто используется кэшем в качестве валидатора. Иными словами, запись в кэше рассматривается как пригодная, если объект не был модифицирован с момента, указанного в Last-Modified.
12.8. 2 Валидаторы кэша для меток объектов (Entity Tag Cache Validators)
Значение поля заголовка объекта ETag (Entity Tag - метка объекта), представляет собой “непрозрачный” валидатор кэша. Это может гарантировать большую надежность при контроле пригодности в ситуациях, когда неудобно запоминать модификации дат, где недостаточно односекундного разрешения для значения даты HTTP или где исходный сервер хочет избежать определенных парадоксов, которые могут возникнуть от использования дат модификации.
Метки объекта обсуждаются в разделе 3.10. Заголовки, используемые с метками объектов, рассмотрены в разделах 13.20, 13.25, 13.26 и 13.43.
12.8.3 Слабые и сильные валидаторы
Так как исходные серверы и кэши будут сравнивать два валидатора, чтобы решить, представляют ли они один и тот же объект, обычно подразумевается, что, если объект (тело объекта или любой заголовок) изменяется каким-либо образом, то и сопряженный валидатор изменится. Если это так, такой валидатор называется "сильным ".
Однако могут встретиться случаи, когда сервер предпочитает изменять валидатор только при семантически существенных изменениях. Валидатор, который не изменяется всякий раз при изменении ресурса, называется "слабым".
Метки объекта обычно являются "сильными валидаторами", но протокол предлагает механизм установки "слабой" метки объекта. Можно считать, что сильный валидатор это такой, который изменяется, если меняется хотя бы один бит в объекте, в то время как значение слабого изменяется при вариации значения объекта. Альтернативой можно считать точку зрения, при которой сильный валидатор является частью идентификатора конкретного объекта, в то время как слабый валидатор является частью идентификатора набора семантически эквивалентных объектов.
Замечание. Примером сильного валидатора является целое число, которое увеличивается на единицу всякий раз, когда в объект вносится какое-либо изменение.
Время модификации объекта при односекундном разрешении может быть лишь слабым валидатором, так как имеется возможность того, что ресурс может быть модифицирован дважды в течение одной и той же секунды.
Поддержка слабых валидаторов является опционной. Однако слабый валидатор позволяет более эффективно кэшировать эквивалентные объекты.
Валидатор используется либо, когда клиент генерирует запрос и включает валидатор в поле заголовка проверки годности, или когда сервер сравнивает два валидатора.
Сильные валидаторы могут использоваться в любом контексте. Слабые валидаторы применимы только в контексте, который не зависит от точной эквивалентности объектов. Например, как один, так и другой вид валидаторов применим для условного GET. Однако, только сильный валидатор применим для фрагментированного извлечения ресурсов, так как в противном случае клиент может прервать работу с внутренне противоречивым объектом.
Единственной функцией протокола HTTP/1.1, определенной для валидаторов, является сравнение. Существует две функции сравнения валидаторов, в зависимости от того, допускает ли контекст использование слабых валидаторов или нет:
Функция сильного сравнения. Для того, чтобы считаться равными оба валидатора должны быть идентичными, и не один из них не должен быть слабым.
Функция слабого сравнения. Для того, чтобы считаться равными оба валидатора должны быть идентичными, но либо оба, либо один из них могут иметь метку "слабый" без какого-либо воздействия на результат.
Функция слабого сравнения может быть использована для простых (non-subrange – не фрагментных) GET-запросов. Функция сильного сравнения должна быть использована во всех прочих случаях.
Метка объекта является сильной, если она не помечена явно как слабая. В разделе 2.11 рассматривается синтаксис меток объектов.
Параметр Last-Modified time, при использовании в качестве валидатора запроса, является неявно (подразумевается) слабым, если не возможно установить, что он сильный, используя следующие правила:
Валидатор сравнивается исходным сервером с текущим рабочим валидатором для данного объекта и,
Исходный сервер твердо знает, что соответствующий объект не изменялся дважды за секунду, к которой привязан настоящий валидатор.
Или
Валидатор предполагается использовать клиентом в заголовке If-Modified-Since или If-Unmodified-Since, так как клиент имеет запись в кэше для соответствующего объекта, и
Эта запись в кэш включает в себя значение Date, которое определяет время, когда исходный сервер послал оригинал запроса, и
Предлагаемый параметр Last-Modified time соответствует моменту времени, по крайней мере, на 60 секунд раньше значения Date.
или
Валидатор сравнивается промежуточным кэшем с валидатором, запомненным в записи для данного объекта, и
Эта запись в кэше включает в себя значение Date, которое определяет время, когда исходный сервер послал оригинал запроса, и
Предлагаемый параметр Last-Modified time соответствует моменту времени, по крайней мере, на 60 секунд раньше значения Date.
Этот метод базируется на том факте, что, если два различных отклика были посланы исходным сервером в пределах одной и той же секунды, но оба имеют одно и то же время Last-Modified, тогда, по крайней мере, один из этих откликов имеет значение Date равное его времени Last-Modified. Произвольный 60-секундный лимит предохраняет против возможности того, что значения Date и Last-Modified сгенерированы с использованием различных часов или в несколько разные моменты времени при подготовке отклика. Конкретная реализация может использовать величину больше 60 секунд, если считается, что 60 секунд слишком мало.
Кэш или исходный сервер, получающий условный запрос кэша, отличный от GET-запроса, должен использовать функцию сильного сравнения, чтобы оценить условие.
Эти правила позволяют кэшам HTTP/1.1 и клиентам безопасно произвести фрагментный доступ к ресурсам на глубину, которая получена от серверов HTTP/1.0.
12.8.4 Правила того, когда использовать метки объекта и даты последней модификации
Мы принимаем набор правил и рекомендаций для исходных серверов, клиентов и кэшей относительно того, когда должны использоваться различные типы валидаторов и для каких целей.
Исходный сервер HTTP/1.1:
Должен послать валидатор метки объекта, если только возможно его сгенерировать.
Может послать слабую метку объекта вместо сильной, если рабочие соображения поддерживают использования слабых меток объекта или если невозможно послать сильную метку объекта.
Должен послать значение Last-Modified, когда это возможно сделать, если только риск нарушения семантической прозрачности, которое может явиться следствием использования этой даты в заголовке, не приведет к серьезным проблемам.
Другими словами предпочтительным поведением для исходного сервера HTTP/1.1 является посылка сильной метки объекта и значения Last-Modified.
Для сохранения легальности сильная метка объекта должна изменяться всякий раз, когда каким-либо образом меняется ассоциированное значение объекта. Слабую метку объекта следует менять всякий раз, когда соответствующий объект изменяется семантически значимым образом.
Замечание. Для того, чтобы обеспечить семантически прозрачное кэширование, исходный сервер должен избегать повторного использования специфических, сильных меток для двух разных объектов, или повторного использования специфических, слабых меток для двух семантически разных объектов. Записи в кэш могут существовать сколь угодно долгое время вне зависимости от времени годности. Таким образом, может оказаться неразумным ожидать, что кэш никогда вновь не попытается перепроверить запись, используя валидатор, который он получил в какой-то момент в прошлом.
Клиенты HTTP/1.1:
Если метка объекта была прислана исходным сервером, эта метка должна быть использована в любом условном запросе кэша (с If-Match или If-None-Match).
Если только значение Last-Modified было прислано исходным сервером, оно должно использоваться в нефрагментных, условных запросах кэша (с использованием If-Modified-Since).
Если только значение Last-Modified было прислано исходным сервером HTTP/1.0, оно может использоваться в фрагментных, условных запросах кэша (с использованием If-Unmodified-Since:). Агенту пользователя следует обеспечить способ блокировки этого в случае возникновения трудностей.
Если и метка объекта и значение Last-Modified были присланы исходным сервером, в условных запросах кэша следует использовать оба валидатора.
Это позволяет корректно реагировать кэшам, поддерживающим как HTTP/1.0, так и HTTP/1.1.
Кэш HTTP/1.1 при получении запроса должен использовать наиболее регламентирующий валидатор, когда проверяется, соответствуют ли друг другу запись в буфере клиента и собственная запись в кэше. Это единственный выход, когда запрос содержит как метку объекта, так и валидатор last-modified-date (If-Modified-Since или If-Unmodified-Since).
Базовым принципом всех этих правил является то, что HTTP/1.1 серверы и клиенты должны пересылать как можно больше надежной информации в своих запросах и откликах. HTTP/1.1 системы, принимая эту информацию, используют наиболее консервативное предположение относительно валидаторов, которые они получают.
Клиенты HTTP/1.0 и кэши будут игнорировать метки объектов. Вообще, значения времени последней модификации, полученные или используемые этими системами, будут поддерживать прозрачное и эффективное кэширование и, по этой причине, исходные серверы HTTP/1.1 должны присылать значения параметров Last-Modified. В тех редких случаях, когда в качестве валидатора системой HTTP/1.0 используется значение Last-Modified, могут возникнуть серьезные проблемы, и тогда исходные серверы HTTP/1.1 присылать их не должны.
12.8.5 Условия пригодности
Принцип использования меток объектов базируется на том, что только автор услуг знает семантику ресурсов достаточно хорошо, чтобы выбрать подходящий механизм контроля кэширования. Спецификация любой функции сравнения валидаторов более сложна, чем сравнение байтов. Таким образом, для целей проверки пригодности записи в кэше никогда не используется сравнение любых других заголовков кроме Last-Modified, для совместимости с HTTP/1.0.
12.9. Кэшируемость отклика
Если только нет специального ограничения директивой Cache-Control (раздел 13.9), система кэширования может всегда запоминать отклик (см. раздел 12.8) в качестве записи в кэш, может прислать его без проверки пригодности, если он является свежим, и может послать его после успешной проверки пригодности.
Если нет ни валидатора кэша ни времени пригодности, ассоциированного с этим откликом, мы не ожидаем, что такой отклик будет кэширован, но некоторые кэши могут нарушить это правило (например, когда имеется плохая коннективность или она вообще отсутствует). Клиент обычно может детектировать, что такой отклик был взят из кэша после сравнения заголовка Date с текущим временем.
Заметьте, что некоторые кэши HTTP/1.0 нарушают эти правила, даже не присылая предупреждения.
Однако, в некоторых случаях может быть неприемлемо для кэша сохранять объект или присылать его в ответ на последующие запросы. Это может быть потому, что автор сервиса полагает необходимой абсолютную семантическую прозрачность по соображениям безопасности или конфиденциальности. Определенные директивы Cache-Control предназначены для того, чтобы сервер мог указать, что некоторые объекты ресурсов или их части не могут кэшироваться ни при каких обстоятельствах.
Заметьте, что раздел 13.8 в норме препятствует кэшу запоминать и отсылать отклик на предыдущий запрос, если этот запрос включает в себя заголовок авторизации.
Отклик, полученный со статусным кодом 200, 203, 206, 300, 301 или 410, может быть запомнен кэшем и использован в ответе на последующие запросы, если директива не препятствует кэшированию. Однако, кэш, который не поддерживает заголовки Range и Content-Range не должен кэшировать отклики 206 (Partial Content).
Отклик, полученный с любым другим статусным кодом, не должен отсылаться в ответ на последующие запросы, если только нет директив Cache-Control или других заголовков, которые напрямую разрешают это. К таким, например, относятся: заголовок Expires (раздел 13.21); "max-age", "must-revalidate", "proxy-revalidate", "public" или "private" директива Cache-Control (раздел 13.9).
12.10 Формирование откликов кэшей
Целью кэша HTTP является запоминание информации, полученной в откликах на запросы, для использования в ответ на будущие запросы. Во многих случаях, кэш просто отсылает соответствующие части отклика отправителю запроса.
Однако, если кэш содержит объект, базирующийся на предшествующем отклике, он может быть вынужден комбинировать части нового отклика с тем, что хранится в объекте кэша.
12.10.1 Заголовки End-to-end (точка-точка) и Hop-by-hop (шаг-за-шагом)
Для целей определения поведения кэшей и некэшурующих прокси-серверов заголовки HTTP делятся на две категории:
Заголовки End-to-end, которые должны быть пересланы конечному получателю запроса или отклика. Заголовки End-to-end в откликах должны запоминаться как часть объекта кэша и пересылаться в любом отклике, полученном из записи кэша.
Заголовки Hop-by-hop, которые имеют смысл только для одноуровневого транспортного соединения, они не запоминаются кэшем и не переадресуются прокси-серверами.
Следующие заголовки HTTP/1.1 относятся к категории hop-by-hop:
Connection
Keep-Alive
Public
Proxy-Authenticate
Transfer-Encoding
Upgrade
Все другие заголовки, определенные HTTP/1.1 относятся к категории end-to-end.
Заголовки Hop-by-hop, вводимые в будущих версиях HTTP, должны быть перечислены в заголовке Connection, как это описано в разделе 13.10.
12.10.2 Немодифицируемые заголовки
Некоторые черты протокола HTTP/1.1, такие как Digest Authentication, зависят от значения определенных заголовков end-to-end. Кэш или некэширующий прокси не должны модифицировать заголовок end-to-end, если только определение этого заголовка не требует или не разрешает этого.
Кэш или некэширующий прокси не должны модифицировать любое из следующих полей запроса или отклика или добавлять какие-либо поля, если они еще не существуют:
Content-Location
Etag
Expires
Last-Modified
Кэш или некэширующий прокси не должны модифицировать или добавлять следующие поля в любых запросах и в откликах, которые содержат директиву no-transform Cache-Control:
Content-Encoding
Content-Length
Content-Range
Content-Type
Кэш или некэширующий прокси могут модифицировать или добавлять эти поля в отклик, который не включает директиву no-transform. Если же он содержит эту директиву, следует добавить предупреждение 14 (Transformation applied), если оно еще не занесено в отклик.
Предупреждение. Ненужная модификация заголовков end-to-end может вызвать отказы в авторизации, если в поздних версиях HTTP использован более строгий механизм. Такие механизмы авторизации могут использовать значения полей заголовков не перечисленных здесь.
12.10.3 Комбинирование заголовков
Когда кэш делает запрос серверу о пригодности ресурса и сервер выдает отклик 304 (Not Modified), кэш должен подготовить и отправить отклик, чтобы послать клиенту. Кэш использует тело объекта из записи в кэше при формировании отклика. Заголовки end-to-end записанные в кэше, используются для конструирования отклика. Исключение составляют любые end-to-end заголовки, поступившие в рамках отклика 304, они должны заместить соответствующие заголовки из записи в кэше. Если только кэш не решил удалить запись, он должен также заменить end-to-end заголовки своей записи соответствующими заголовками из полученного отклика.
Другими словами, набор end-to-end заголовков, полученный вместе откликом переписывает все соответствующие end-to-end заголовки, из записи в кэше. Кэш может добавить к этому набору заголовки предупреждений (см. раздел 13.45).
Если имя поля заголовка приходящего отклика соответствует более чем одной записи в кэше, все старые заголовки заменяются.
Замечание. Это правило позволяет исходному серверу использовать отклик 304 (Not Modified) для актуализации любого заголовка, связанного с предыдущим откликом для того же объекта, хотя это может не всегда иметь смысл. Это правило не позволяет исходному серверу использовать отклик 304 (not Modified) для того, чтобы полностью стереть заголовок, который был прислан предыдущим откликом.
12.10.4 Комбинирование байтовых фрагментов
Отклик может передать только субдиапазон байтов тела объекта, либо потому, что запрос включает в себя один или более спецификаций Range, либо из-за преждевременного обрыва соединения. После нескольких таких передач кэш может получить несколько фрагментов тела объекта.
Если кэш запомнил не пустой набор субфрагментов объекта, а входящий отклик передает еще один фрагмент, кэш может комбинировать новый субфрагмент с уже имеющимся набором, если для обоих выполняются следующие условия:
Оба приходящие отклика и запись в кэше должны иметь валидатор кэша.
Оба валидатора кэша должны соответствовать функции сильного сравнения (см. раздел 12.8.3).
Если любое из условий не выполнено, кэш должен использовать только наиболее поздний частичный отклик и отбросить другую частичную информацию.
12.11. Кэширование согласованных откликов
Использование согласования содержимого под управлением сервера (раздел 11), что индицируется присутствием поля заголовка Vary в отклике, изменяет условия и процедуру, при которой кэш может использовать отклик для последующих запросов.
Сервер должен использовать поле заголовка Vary (раздел 13.43), чтобы информировать кэш о том, какие пределы для поля заголовка используются при выборе представления кэшируемого отклика. Кэш может использовать выбранное представление для ответов на последующие запросы, только когда они имеют те же или эквивалентные величины полей заголовка, специфицированных в заголовке отклика Vary. Запросы с различными значениями одного или нескольких полей заголовка следует переадресовывать исходному серверу.
Если представлению присвоена метка объекта, переадресуемый запрос должен быть условным и содержать метки в поле заголовка If-None-Match всех его кэшированных записей для Request-URI. Это сообщает серверу набор объектов, которые в настоящее время хранятся в кэше, так что, если любая из этих записей соответствует запрашиваемому объекту, сервер может использовать заголовок ETag в своем отклике 304 (Not Modified), чтобы сообщить кэшу, какой объект подходит. Если метка объекта нового отклика соответствует существующей записи, новый отклик должен быть использован для актуализации полей заголовка существующей записи, а результат должен быть прислан клиенту.
Поле заголовка Vary может также информировать кэш, что представление было выбрано с использованием критериев помимо взятых из заголовков запросов. В этом случае, кэш не должен использовать отклик в ответ на последующий запрос, если только кэш не передает исходному серверу условный запрос.
Сервер при этом возвращает отклик 304 (Not Modified), включая метку объекта или поле Content-Location, которые указывают, какой объект должен быть использован.
Если какая-то запись кэша содержит только часть информации для соответствующего объекта, его метка не должна содержаться в заголовке If-None-Match, если только запрос не лежит в диапазоне, который полностью покрывается этим объектом.
Если кэш получает позитивный отклик с полем Content-Location, соответствующим записи в кэше для того же Request-URI, с меткой объекта, отличающейся от метки существующего объекта, и датой современнее даты существующего объекта, данная запись не должна использоваться в качестве отклика для будущих запросов и должна быть удалена из кэша.
12.12. Кэши коллективного и индивидуального использования
По причинам безопасности и конфиденциальности необходимо делать различие между кэшами совместного и индивидуального использования. Индивидуальные кэши доступны только для одного пользователя. Доступность в этом случае должна определяться соответствующим механизмом, обеспечивающим безопасность. Все другие кэши рассматриваются как коллективные. Другие разделы этой спецификации накладывают определенные ограничения на работу совместно используемых кэшей, для того, чтобы предотвратить потерю конфиденциальности или управления доступом.
12.13. Ошибки и поведение кэша при неполном отклике
Кэш, который получает неполный отклик (например, с меньшим числом байтов, чем специфицировано в заголовке Content-Length) может его запомнить. Однако, кэш должен воспринимать эти данные как частичный отклик. Частичные отклики могут компоноваться, как это описано в разделе 12.5.4. Результатом может быть полный или частичный отклик. Кэш не должен
возвращать частичный отклик клиенту без явного указания на то, что он частичный, используя статусный код 206 (Partial Content). Кэш не должен возвращать частичный отклик, используя статусный код 200 (OK).
Если кэш получает отклик 5xx при попытке перепроверить запись, он может переадресовать этот отклик запрашивающему клиенту или действовать так, как если бы сервер не смог ответить на запрос.
В последнем случае он может вернуть отклик, полученный ранее, если только запись в кэше не содержит директиву Cache-Control "must-revalidate" (см. раздел 13.9).
12.14. Побочные эффекты методов GET и HEAD
Если исходный сервер напрямую не запрещает кэширование своих откликов, методы приложения GET и HEAD не должны давать каких-либо побочных эффектов, которые вызывали бы некорректное поведение, если эти отклики берутся из кэша. Они все же могут давать побочные эффекты, но кэш не обязан рассматривать такие побочные эффекты, принимая решение о кэшировании. Кэши контролируют лишь прямые указания исходного сервера о запрете кэширования.
Обратим внимание только на одно исключение из этого правила: некоторые приложения имеют традиционно используемые GET и HEAD с запросами URL (содержащими "?" в части rel_path) для выполнения операций с ощутимыми побочными эффектами. Кэши не должны
обрабатывать отклики от таких URL, как свежие, если только сервер не присылает непосредственно значение времени жизни. Это в частности означает, что отклики от серверов HTTP/1.0 для этих URI не следует брать из кэша. Дополнительную информацию по смежным темам можно найти в разделе 8.1.1.
12.15 Несоответствие после актуализации или стирания
Воздействие определенных методов на исходный сервер может вызвать то, что одна или более записей, имеющихся в кэше, становятся неявно непригодными. То есть, хотя они могут оставаться "свежими", они не вполне точно отражают то, что исходный сервер пришлет в ответ на новый запрос.
В протоколе HTTP не существует способа гарантировать, что все такие записи в кэше будут помечены как непригодные. Например, запрос, который вызывает изменение в исходном сервере не обязательно проходит через прокси, где в кэше хранится такая запись. Однако несколько правил помогает уменьшить вероятность некорректного поведения системы.
В этом разделе, выражение "пометить объект как непригодный" означает, что кэш должен либо удалить все записи, относящиеся к этому объекту из памяти или должен пометить их, как непригодные ("invalid"), что будет вызывать обязательную перепроверку пригодности перед отправкой в виде отклика на последующий запрос.
Некоторые методы HTTP могут сделать объект непригодным. Это либо объекты, на которые осуществляется ссылка через Request-URI, или через заголовки отклика Location или Content-Location (если они имеются). Это методы:
PUT
DELETE
POST
12.16. Обязательная пропись (Write-Through Mandatory)
Все методы, которые предположительно могут вызвать модификацию ресурсов исходного сервера должны быть прописаны в исходный сервер. В настоящее время сюда входят все методы кроме GET и HEAD. Кэш не должен отвечать на такой запрос от клиента, прежде чем передаст запрос встроенному (inbound) серверу, и получит соответствующего отклик от него. Это не препятствует кэшу послать отклик 100 (Continue), прежде чем встроенный сервер ответит.
Альтернатива, известная как "write-back" или "copy-back" кэширование, в HTTP/1.1 не допускается, из-за трудности обеспечения согласованных актуализаций и проблем, связанных с отказами сервера, кэша или сети до осуществления обратной записи (write-back).
12.17. Замещения в кэше
Если от ресурса получен новый кэшируемый отклик (см. разделы 13.9.2, 12.5, 12.6 и 12.8), в то время как какой-либо отклик для того же ресурса уже записан в кэш, кэшу следует использовать новый отклик для ответа на текущий запрос. Он может ввести его в память кэша и может, если он отвечает всем требованиям, использовать в качестве отклика для будущих запросов. Если он вводит новый отклик в память кэша, он должен следовать правилам из раздела 12.5.3.
Замечание. Новый отклик, который имеет значение заголовка Date старше, чем кэшированные уже отклики, не должен заноситься в кэш.
12.18. Списки предыстории
Агенты пользователя часто имеют механизмы "исторического" управления, такие как кнопки "Back" и списки предыстории, которые могут использоваться для повторного отображения объекта, извлеченного ранее в процессе сессии. Механизмы предыстории и кэширования различны. В частности механизмы предыстории не должны пытаться показать семантически прозрачный вид текущего состояния ресурса.Скорее, механизм предыстории предназначен для того, чтобы в точности показать, что видел пользователь, когда ресурс был извлечен. По умолчанию время годности не приложимо к механизмам предыстории. Если объект все еще в памяти, механизм предыстории должен его отобразить, даже если время жизни объекта истекло и он объявлен непригодным, если только пользователь не сконфигурировал агента так, чтобы обновлять объекты, срок годности которых истек. Это не запрещает механизму предыстории сообщать пользователю, что рассматриваемый им объект устарел.
Замечание. Если механизмы предыстории излишне мешают пользователю просматривать устаревшие ресурсы, то это заставит разработчиков избегать пользоваться контролем времени жизни объектов. Разработчикам следует считать важным, чтобы пользователи не получали сообщений об ошибке или предупреждения, когда они пользуются навигационным управлением (например, таким как клавиша BACK).
