Тег header. Классы, селекторы и свойства в CSS
Начало урока. Разбор файла index.html
В index.html по сравнению с предыдущим уроком изменилось немного. Я только добавил после <body> следующий код:
<header> </header>
Верхнюю часть сайта, называемую «шапка», помещают в специальный тег <header></header>.
На вашем сайте в <header></header> будет вся красная верхушка, как на imdiz.ru/store/:
Цвет фона для header я задал свойством background в style.css. Если Вы еще не открыли файл style.css в SublimeText, то откройте.
Сейчас у Вас в SublimeText открыто 2 файла: index.html и style.css. Для удобства сделайте следующее: вверху SublimeText нажмите View, в выпавшем окне наведите на Layout, и выберите там Columns: 2. Ваш редактор разделится на 2 колонки и файлы можно разместить в разных колонках. Так вы будете видеть сразу оба файла. Смотрите видео:
youtube.com/embed/6uTIkJKG6S0″ frameborder=»0″ allowfullscreen=»allowfullscreen»>Разбор файла style.css
Разберем файл style.css и заодно познакомимся с CSS.
Сперва пропустим верхнюю часть кода и перейдем к участку:
.header{ background: #cb2d41; height: 100px; }
Говоря по-русски, благодаря этому коду браузер будет искать в index.html тег с классом header и задаст этому тегу цвет фона #cb2d41 и высоту 100px.
А теперь по-подробнее.
Этот код задает стили для <header>, который находится в index.html. Здесь задан цвет фона (background) и высота (height).
Посмотрите на картинку ниже, на ней изображена структура стилей в CSS:
То есть структура следующая. Сперва пишется селектор, в нашем случае это класс .header. Именно по селектору браузер определяет, для какого тега в index.html нужно применить CSS-свойства. В фигурных скобках прописываются нужные CSS-стили для этого селектора: свойство и значение этого свойства.
#cb2d41 — такой формат задания цвета называется HEX. Это наиболее частый формат в верстке сайтов. Цвет можно задать просто английским словом, например, background: red. Но чаще (а точнее, практически всегда) применяется именно формат HEX.
В index.html я задал тегу header класс «header». И в style.css задал стили для этого класса — .header. В CSS точка перед названием селектора означает, что это селектора класса.
В профессиональной верстке использовать селектор класса это почти стандарт, и нужно всегда стараться использовать именно селектор класса.
Кстати, название класса может быть абсолютно любым, хоть abcdef, но все-таки удобнее называть классы по смыслу элемента. У нас таким элементом является тег <header>, и здесь можно не выдумывать велосипед и назвать класс тоже header.
В нашем коде для .header помимо background задана еще и высота height: 100px;.
Переопределение стилей браузера. Инструменты разработчика в браузере
Теперь в Вашем style.css вернитесь к участку кода:
html, body{ margin: 0; }
Селекторы можно прописывать через запятую. В данном случае CSS-стили в фигурных скобках будут применены и для тега html, и для тега body.
Этот код равнозначен следующему:
html{ margin: 0; } body{ margin: 0; }
И еще обратите внимание, что здесь используется селектор тега, а не класса. Точка перед именем селектора не стоит.
А теперь о том, для чего нужен этот участок кода. Если Вы удалите этот участок кода и сохраните style.css, то увидите в браузере, что шапка не на всю ширину браузера (слева, справа, а также сверху, будут белые полоски). Это потому, что в каждом браузере уже прописаны некоторые стили для всех HTML-тегов. Это стили браузера по умолчанию. В нашем случае белые полосы будут из-за того, что для тега <body></body> в браузере указаны отступы (в CSS для этого используется свойство margin). Чтобы это увидеть вызовите в браузере средства разработчика. Для этого, если у вас Google Chrome или Yandex Browser, просто нажмите на клавиатуре F12.
С инструментами разработчика удобнее работать, когда окно открыто внизу. Для того, чтобы его перенести вниз, нажмите справа на 3 точки, и в открывшемся окошке выберите нужное расположение. Смотрите видео:
В средствах разработчика видна структура HTML, а справа CSS-стили выделенного HTML-тега. Если Вы нажмете на <body>, то справа в CSS увидите, что помимо наших стилей у body есть еще другие стили, и в них margin: 8px;.
Комментарии в HTML
Помните в начале урока написано, что новые участки кода находятся между <!— New —><!— End —>. Сами <!— New —> и <!— End —> никак не отобразятся в браузере. С помощью <!— —> осуществляется комментирование в HTML. Всё, что Вы поместите внутрь данной конструкции не отобразится в браузере, оно будет закомментировано. С помощью комментариев можно помещать какие-то подсказки для себя. Также, комментировать можно некоторые участки кода, чтобы временно их скрыть, при этом не придется их удалять.
Подытожу этот урок тем, что в CSS не так уж много свойств и их значений. На практике все CSS-свойства быстро запоминаются. Все CSS-свойства являются английскими словами, например, height переводится «высота». И это тоже очень хорошо для запоминания CSS-свойств.
Конец урока. В данном уроке вы узнали:
background — CSS-свойство для задания фона HTML-элемента
height — свойство для задания высоты
margin — внешние отступы
<header></header> — тег для «шапки» сайта.
Блок не отображается на сайте, если он пустой или ему не задана высота.
Стандартные стили браузера нужно переопределять.
В Google Chrome и Yandex Browser есть инструменты разработчика, которые вызываются клавишей F12.
Стили в CSS задаются через селекторы. В качестве селектора нужно стараться выбирать класс HTML-элемента.
Источник: convertmonster.ru
117 просмотров
Дизайн сайта состоит из множества взаимосвязанных элементов, которые создают цельную картинку. Для создания качественного и конверсионного сайта нужно прорабатывать каждый его элемент. Поэтому в этой статье разберемся, как сделать хедер и футер сайта, которые помогут увеличить конверсию сайта.
Что такое хедер и футер сайта
Хедер сайта, или шапка сайта — это его верхняя часть. Header сайта располагается как отдельный блок, отображающийся вверху на каждой странице сайта. Как правило, хедер содержит в себе ссылки на разделы сайта или важные категории, название компании, логотип, а также контактные данные.
Шапка сайта (header) может быть идентичной на каждой странице сайта, или же различаться. При использовании разных хедеров на страницах нужно следить за тем, чтобы примеры header для внутренней страницы сайта были сокращенным вариантами хедера, применяемого на главной странице.
Красивый header для сайта нужен не только для придания индивидуальности, но и для увеличения процента конверсии, а также перемещения пользователя по сайту. Поэтому некачественно выполненный хедер сайта заставляет пользователей уходить с него.
Header и footer составляют структуру сайта, но header сайта является противоположным элементом footer.
Футер, или подвал сайта — это часть, которая находится внизу страниц сайта. Футер сайта располагается ниже основного контента, что позволяет ему выполнять определенные функции.
Так, footer сайта содержит такие элементы, как карта сайта, полезные ссылки, отзывы, награды, социальные сети, ссылки на второстепенные задачи и так далее. Поэтому красивый футер для сайта может способствовать дополнительному числу лидов. Некоторым пользователям могут быть интересны дополнительные предложения, находящиеся в футере, или захочется посмотреть на социальные сети компании.
Как сделать хедер для сайта
Для того чтобы сделать header для сайта, разберемся в первую очередь с его размером. Размер хедера для сайта составляет 1024 px в ширину, но он может варьироваться от 1024 px до 1920 px.
Разберем 5 основных советов по созданию хедера сайта.
1. Выберите, что будет содержать хедер.
Как сказано выше, хедер может включать в себя различные элементы и информацию. Поэтому важно выбрать те приоритетные данные, которые будут на нем размещены. Необходимым является размещение названия, логотипа, навигации, заголовка страницы, корзины покупателя, вход/выход.
2. Решите, какой у хедера будет шрифт.
Если у компании есть фирменный шрифт, то лучше использовать его. Если нет, используйте простые и хорошо читаемые шрифты, которые сочетаются со шрифтом остальных частей сайта.
3. Используйте логотип в хорошем качестве.
В хедере, как правило, не используются изображения, за исключением логотипа. Поэтому он должен иметь высокое разрешение.
4. Не перегружайте шапку ненужной информацией.
Перегруженная шапка сайта может негативно повлиять на его конверсию. Пользователи не будут читать много информации, чтобы найти то, что нужно им. Оставляйте только то, что способствует главной цели — привлечению лидов.
5. Выбирайте фиксированный скролинг.
Если в шапку сайта вы поместили важную информацию, то используйте фиксированный скролинг. Это нужно для того, чтобы эта информация оставалась на виду у пользователя. Например, это эффективно, когда в хедере есть кнопка лидогенерации.
При создании хедера нередко возникают сложности.
- В хедере название и контакты не должны быть отображены как картинки. Эти разделы должны быть в виде текста, чтобы их воспринимали поисковые системы.
- Нельзя использовать изображения, которые много весят, а также флеш-элементы и большое количество графики. Их применение увеличит время загрузки страницы, что негативно скажется на посещаемости сайта.
- Горизонтальное меню нужно отображать, используя исключительно текст. Картинки и флеш не подходят. Это важно, чтобы в дальнейшем без проблем вносить в него изменения.
- Применение только h2 заголовка, который является одинаковым для каждой страницы сайта, негативно скажется, когда вы займетесь продвижением сайта.
- Разрабатывайте HTML-шапки. Это проще, чем использовать хедеры из каринки или флеш-элементов. В качестве альтернативы в дизайны, которые работают на скриптах, можно добавлять динамические объекты.
- Следите за высотой шапки сайта. Если работаете над информационным ресурсом, то оптимальный размер высоты шапки составляет 100-200 пикселей. Для лендингов, а также сайтов-визиток можно сделать хедер выше. Важно, чтобы хедер не мешал пользователям воспринимать контент на сайте.
Примеры хедера сайта
Как сделать футер сайта
1. Определитесь с видом футера.
Помимо стандартного футера есть два варианта футеров для сайта. Во-первых, футер для бесконечного скролла, когда новый контент постоянно подгружается при прокрутке вниз. В таком случае футер переносят и он становится сбоку от бесконечной ленты. Во-вторых, контекстный футер, который подбирается для каждой страницы индивидуально.
2. Выберите элементы, которые будут отображены на футере.
Важно понимать, что элементы футера не должны дублировать хедер. Например, на футер можно поместить ссылки на полезные статьи, отзывы, взаимодействие с клиентами, ссылки на вторичные задачи и так далее.
3. Не делайте больше, чем два уровня иерархии.
Футер не должен выглядеть сложным или нагроможденным. Делайте его простым и понятным любому пользователю. Минимализм и лаконичность — ключ к хорошему футеру.
4. Делайте футер заметным, а текст разборчивым.
Посетители сайта должны видеть, что им предлагается. Футер не должен быть незаметным или содержать мелкий шрифт. Шрифт футера должен быть меньше основного, но быть читаемым.
5. Используйте корректные имена ссылок
Ссылки на футере должны называться так, чтобы пользователь понимал, что он получит, когда по ним перейдет. Используйте понятные названия ссылок. В этом разделе лучше не креативить.
Примеры footer для сайта
В качестве примеров футера сайта можно привести следующие варианты:
onplay | Скрипт викликається коли медіа дані готові почати відтворення. |
onafterprint | Скрипт виконується тільки після як документ надрукований. |
onbeforeprint | Скрипт виконується перед тим, як документ надрукований. |
onbeforeunload | Скрипт виконується коли документ ось-ось буде вивантажений |
onhashchange | Скрипт виконується коли там відбулися зміни до частини якоря в URL |
onload | Викликається після того як завантаження елемента завершене. |
onmessage | Скрипт виконується коли викликане повідомлення. |
onoffline | Спрацьовує коли браузер починає працювати в автономному режимі |
ononline | Спрацьовує коли браузер починає працювати в режимі онлай. |
onpagehide | Скрипт виконується коли користувач переходить на іншу сторінку сторінку. |
onpageshow | Скрипт виконується коли користувач заходить на сторінку. |
onpopstate | Скрипт виконується коли змінено історію одного вікна. |
onresize | Скрипт виконується, коли розмір вікна браузера змінюється. |
onstorage | Скрипт виконується, коли вміст Web Storage оновлюється. |
onunload | Викликається, коли сторінка розвантажена, або вікно браузера було зачинено. |
onblur | Скрипт виконується, коли елемент втрачає фокус. |
onchange | Викликається в той момент, коли значення елемента змінюється. |
oncontextmenu | Скрипт виконується коли викликається контекстне меню. |
onfocus | Викликається в той момент, коли елемент отримує фокус. |
oninput | Скрипт викликається коли користувач вводить дані поле. |
oninvalid | Скрипт виконується, коли елемент недійсний. |
onreset | Викликається, коли натискається у формі кнопка типу Reset. |
onsearch | Викликається, коли користувач щось пише в поле пошуку (для <input type="search">) |
onselect | Викликаєтсья після того як будь-який текст був обраний в елементі. |
onsubmit | Викликається при відправленні форми. |
onkeydown | Подія викликається, коли користувач затис (натиснув та не відпускає) клавішу. |
onkeypress | Викликається коли корисрувач натиснув на клавішу. |
onkeyup | Викликається коли користувач відпускає клавішу. |
ondblclick | Виникає при подвійному клацанні ЛКМ на елементі. |
ondrag | Періодично викликається при операції перетягування. |
ondragend | Викликається коли користувач відпускає перелягуваний елемент. |
ondragenter | Викликається, коли перетягуваний елемент входить в цільову зону. |
ondragleave | Викликається, коли перетягуваний елемент виходть з зони призначення. |
ondragover | Викликається, коли перетягуваний елемент знаходиться в зоні призначення. |
ondragstart | Викликається, коли користувач починає перетягувати елемент, або виділений текст. |
ondrop | Викликається, коли перетягуваний елемент падає до зони призначення. |
onmousedown | Викликається, коли користувач затискає ЛКМ на елементі. |
onmousemove | Викликається, коли курсор миші переміщається над елементом. |
onmouseout | Викликається, коли курсор виходить за межі елемента. |
onmouseover | Виконується, коли курсор наводиться на елемент. |
onmouseup | Викликається, коли користувач відпускає кнопку миші. |
onscroll | Викликається при прокручуванні вмісту елемента (чи веб-сторінки). |
onwheel | Викликається, коли користувач прокручує коліщатко миші. |
oncopy | Викликається, коли користувач копіює вміст елемента. |
oncut | Викликається, коли користувач вирізає вміст елемента. |
onpaste | Викликається, коли користувач вставляє вміст в елемент. |
onabort | Виконується при перериванні якоїсь події. |
oncanplay | Скрипт виконується коли файл готовий, для початку відтворення (коли він буферизований достатньо, щоб почати відтворення) |
oncanplaythrough | Скрипт виконується, коли контент вже може бути відтворений без переривання на буферизацію. |
oncuechange | Скрипт виконується коли змінюється кий в <track> елемента |
ondurationchange | Викликається коли змінюється довжина медіа файлу. |
onemptied | Викликається коли доступ до медіа контенту обривається (зникло з’єднання з мережею). |
onended | Викликається коли медіа елемент повністю відтворив свій зміст. |
onshow | Викликається, коли елемент <menu> буде відображено як контекстне меню. |
onloadedmetadata | Скрипт виконується коли метадані (розміри чи тривалість) завантажуються. |
onloadeddata | Викликається коли медіа данні завантажено. |
onloadstart | Викликається коли браузер тільки починає завантажувати медіа дані з сервера. |
onpause | Викликається коли відтворення медіа даних призупинено. |
onplaying | Викликається коли розпочато відтворення медіа даних. |
onprogress | Подія onprogress відбувається, коли браузер завантажує вказане аудіо / відео. |
onratechange | Викликається коли змінюється швидкість відтворення медіа даних. |
onseeked | Викликається коли атрибут seeked у тега audio або video змінює значення з true на false. |
onseeking | Викликається коли атрибут seeking у тегів audio або video змінює значення з false на true |
onstalled | Скрипт виконується коли браузер з будь-якої причини не може отримати медіа дані. |
onsuspend | Скрипт виконується коли з будь-якої причини завантаження данних призупинено до його повного завантаження. |
ontimeupdate | Викликається коли змінилася позиція відтворення елемента <audio> або <video>. |
onvolumechange | Викликається коли змінюється гучність звуку. |
onwaiting | Викликається коли наступний кадр при відтворенні медіа даних недоступний, але браузер очікує що він незабаром завантажиться. |
ontoggle | Викликається, коли користувач відкриває або закриває елемент <details>. |
onerror | Викликається якщо при завантаженні елемента сталася помилка. |
onclick | Подія викликається коли користувач клацає ЛКМ по елементу. |
Тег HTML5 — GeeksforGeeks
Просмотреть обсуждение
Улучшить статью
Сохранить статью
- Уровень сложности: Easy
- Последнее обновление: 22 июл, 2022
Посмотреть обсуждение
Улучшить статью
Сохранить статью
Тег
Синтаксис:
...
Атрибуты : Этот тег поддерживает все глобальные атрибуты в HTML.
Примеры ниже иллюстрируют элемент
Пример 1: Этот пример иллюстрирует использование тега
HTML
3 90 3
|
Выходные0003 Пример 2: В этом примере мы использовали тег Выход: HTML Пример 3: в этом примере. ярлык. Вывод: Тег HTML Поддерживаемые браузеры: HTML является основой веб-страниц, используется для разработки веб-страниц путем структурирования веб-сайтов и веб-приложений. Вы можете изучить HTML с нуля, следуя этому руководству по HTML и примерам HTML. Рекомендуемые статьи Страница : В этом разделе определяются синтаксис и семантика всех стандартных
Поля заголовка HTTP/1.1. Для полей заголовка сущности как отправитель, так и
получатель относится либо к клиенту, либо к серверу, в зависимости от того, кто
отправляет и кто получает сущность. Поле заголовка запроса «Принять» можно использовать для указания определенных носителей.
типы, которые приемлемы для ответа. Заголовки Accept могут быть
используется для указания того, что запрос специально ограничен небольшим
набор желаемых типов, как в случае запроса на встроенный
изображение. Символ звездочки «*» используется для группировки типов носителей в диапазоны,
где «*/*» указывает все типы носителей, а «тип/*» указывает все
подтипы этого типа. Медиа-диапазон МОЖЕТ включать тип носителя
параметры, применимые к этому диапазону. За каждым медиа-диапазоном МОЖЕТ следовать один или несколько accept-params,
начиная с параметра "q" для указания относительного качества
фактор. Первый параметр "q" (если есть) разделяет медиа-диапазон
параметр(ы) из accept-params. Факторы качества позволяют пользователю
или пользовательский агент, чтобы указать относительную степень предпочтения для этого
media-range, используя шкалу qvalue от 0 до 1 (раздел 3.9).
значение по умолчанию q=1. Пример СЛЕДУЕТ интерпретировать как «Я предпочитаю аудио/базовый, но пришлите мне любой аудиофайл».
тип, если он является лучшим из доступных после снижения качества на 80%». Если поле заголовка Accept отсутствует, предполагается, что
клиент принимает все типы носителей. Если поле заголовка Accept присутствует,
и если сервер не может отправить ответ, который является приемлемым
в соответствии с комбинированным значением поля Accept, сервер ДОЛЖЕН
отправить ответ 406 (неприемлемо). Более сложный пример На словах это будет интерпретироваться как «text/html и text/x-c
предпочтительные типы носителей, но если они не существуют, отправьте
text/x-dvi, и если он не существует, отправьте text/plain
организация. " Диапазоны носителей могут быть переопределены более конкретными диапазонами носителей или
конкретные типы носителей. Если к данному
тип, более конкретная ссылка имеет приоритет. Например, имеют следующий приоритет: Коэффициент качества типа носителя, связанный с данным типом, равен
определяется путем нахождения диапазона мультимедиа с наивысшим приоритетом
который соответствует этому типу. Например, приведет к тому, что следующие значения будут связаны: Поле заголовка запроса Accept-Charset может использоваться для указания того, что
наборы символов приемлемы для ответа. Это поле позволяет
клиенты, способные понимать более всеобъемлющие или специальные
целевые наборы символов, чтобы сообщить об этой возможности серверу, который
способный представлять документы в этих наборах символов. Значения набора символов описаны в разделе 3.4. Каждая кодировка МОЖЕТ
получить соответствующее значение качества, которое представляет
предпочтение этой кодировки. Значение по умолчанию: q=1. Примером является Специальное значение "*", если оно присутствует в поле Accept-Charset,
соответствует каждому набору символов (включая ISO-8859-1), который не
упоминается в другом месте в поле Accept-Charset. Если нет "*"
в поле Accept-Charset, то все наборы символов не явно
упомянутые получают значение качества 0, кроме ISO-8859-1, что получает
значение качества 1, если это не указано явно. Если заголовок Accept-Charset отсутствует, по умолчанию любой
набор символов приемлем. Если присутствует заголовок Accept-Charset,
и если сервер не может отправить ответ, который является приемлемым
согласно заголовку Accept-Charset, то сервер ДОЛЖЕН отправить
ответ об ошибке с кодом состояния 406 (неприемлемо), хотя
также допускается отправка неприемлемого ответа. Поле заголовка запроса Accept-Encoding похоже на Accept, но
ограничивает кодирование контента (раздел 3. 5), которое приемлемо в
ответ. Примеры его использования: Сервер проверяет приемлемость кодирования контента в соответствии с
поле Accept-Encoding, используя следующие правила: Если поле Accept-Encoding присутствует в запросе и если
сервер не может отправить ответ, который является приемлемым в соответствии с
Accept-Encoding, то сервер ДОЛЖЕН отправить ответ об ошибке
с кодом состояния 406 (неприемлемо). Если в запросе нет поля Accept-Encoding, сервер МОЖЕТ
предположим, что клиент примет любое кодирование контента. В таком случае,
если "идентичность" является одной из доступных кодировок контента, то
сервер ДОЛЖЕН использовать "идентификационное" кодирование контента, если только он не
дополнительная информация о том, что другое кодирование контента имеет смысл
клиенту. Поле заголовка запроса Accept-Language похоже на Accept, но
ограничивает набор естественных языков, предпочитаемых в качестве
ответ на запрос. Языковые теги определены в разделе 3.10. Каждому диапазону языков МОЖЕТ быть присвоено соответствующее значение качества, которое
представляет собой оценку предпочтений пользователя в отношении языков
определяется этим диапазоном. Значение качества по умолчанию равно "q=1". За
пример, будет означать: «Я предпочитаю датский, но приму британский английский и
другие типы английского языка." Диапазон языка соответствует языковому тегу, если
он точно равен тегу или, если он точно равен префиксу
тег так, чтобы первый символ тега, следующий за префиксом, был "-".
Специальный диапазон "*", если он присутствует в поле Accept-Language,
соответствует каждому тегу, не соответствующему ни одному другому диапазону, присутствующему в
Поле Accept-Language. Фактор качества языка, присвоенный языковому тегу
Поле Accept-Language — это значение качества самого длинного языка.
диапазон в поле, которое соответствует тегу языка. Если нет языка-
диапазон в поле соответствует тегу, фактор качества языка
присвоено значение 0. Если заголовок Accept-Language отсутствует в
запрос, сервер СЛЕДУЕТ предполагать, что все языки одинаково приемлемы. Если
Заголовок Accept-Language присутствует, тогда все языки, которые
которым присвоен коэффициент качества больше 0, являются приемлемыми. Это может противоречить ожиданиям пользователя в отношении конфиденциальности.
заголовок Accept-Language с полными лингвистическими настройками
пользователя в каждом запросе. Обсуждение этого вопроса см.
раздел 15.1.4. Поскольку разборчивость в значительной степени зависит от отдельного пользователя,
рекомендуется, чтобы клиентские приложения делали выбор языкового
предпочтения, доступные пользователю. Если выбор не сделан
доступно, то поле заголовка Accept-Language НЕ ДОЛЖНО указываться в
запрос. Поле общего заголовка Cache-Control используется для указания директив.
которому ДОЛЖНЫ подчиняться все механизмы кэширования на
цепочка запросов/ответов. Директивы определяют поведение, предназначенное для
предотвратить неблагоприятное вмешательство кешей в запрос или
отклик. Эти директивы обычно переопределяют кэширование по умолчанию.
алгоритмы. Директивы кэша являются однонаправленными в том смысле, что наличие
директивы в запросе не означает, что эта же директива
необходимо указать в ответе. Директивы кеша ДОЛЖНЫ передаваться через прокси или шлюз
приложение, независимо от их значимости для этого приложения,
поскольку директивы могут быть применимы ко всем получателям на
цепочка запросов/ответов. Невозможно указать кеш-
директива для конкретного кеша. Когда директива появляется без какого-либо параметра 1#field-name,
директива применяется ко всему запросу или ответу. Когда такой
появляется с параметром 1#field-name, он применяется только к
названному полю или полям, а не остальной части запроса или
отклик. Этот механизм поддерживает расширяемость; реализации
будущие версии протокола HTTP могут применять эти директивы к
поля заголовка, не определенные в HTTP/1.1. Директивы управления кешем можно разбить на эти общие
категории: По умолчанию ответ кэшируется, если требования
метод запроса, поля заголовка запроса и статус ответа
указать, что он кэшируется. Раздел 13.4 обобщает эти значения по умолчанию.
для кеширования. Следующие директивы ответа Cache-Control
разрешить исходному серверу переопределять кешируемость по умолчанию для
отклик: Примечание: Это использование слова частный определяет только те
ответ может быть кэширован и не может гарантировать конфиденциальность
содержание сообщения. Примечание: Большинство кэшей HTTP/1.0 не распознают или не подчиняются этому
директива. Время истечения срока действия объекта МОЖЕТ быть указано источником
сервер с использованием заголовка Expires (см. раздел 14.21). Альтернативно,
это МОЖЕТ быть указано с помощью директивы max-age в ответе. Когда
директива max-age cache-control присутствует в кэшированном ответе,
ответ устарел, если его текущий возраст больше, чем возраст
значение, заданное (в секундах) во время нового запроса для этого
ресурс. Директива max-age для ответа подразумевает, что
ответ кэшируется (т. е. «общедоступен»), если только какой-либо другой, более
также присутствует директива ограничительного кеша. Если ответ включает заголовок Expires и max-age
директива max-age переопределяет заголовок Expires, даже
если заголовок Expires является более строгим. Это правило допускает происхождение
сервер, чтобы обеспечить для данного ответа более длительное время истечения срока действия
кеш HTTP/1.1 (или более поздней версии), чем к кешу HTTP/1.0. Это может быть
полезно, если некоторые кэши HTTP/1.0 неправильно вычисляют возраст или
время истечения, возможно, из-за десинхронизации часов. Многие реализации кэша HTTP/1.0 будут обрабатывать значение Expires, которое
меньше или равно значению даты ответа как эквивалентному
на директиву ответа Cache-Control «no-cache». Если HTTP/1.1
кэш получает такой ответ, и ответ не включает в себя
Поле заголовка Cache-Control, в нем СЛЕДУЕТ рассматривать ответ как
без кэширования, чтобы сохранить совместимость с серверами HTTP/1.0. Примечание: Исходный сервер может использовать относительно новый протокол HTTP.
функция управления кешем, такая как директива «private», на
сети, включая старые кеши, которые не понимают, что
особенность. Исходный сервер должен будет объединить новую функцию
с полем Expires, значение которого меньше или равно
Значение даты. Это предотвратит неправильное использование старых кешей.
кэширование ответа. Обратите внимание, что большинство старых кэшей, не соответствующих этой спецификации,
не реализуйте никаких директив управления кешем. Исходный сервер
желающие использовать директиву управления кешем, которая ограничивает, но не запрещает
предотвращения, кэширование с помощью кеша, совместимого с HTTP/1.1, МОЖЕТ использовать
требование, чтобы директива max-age переопределяла заголовок Expires,
и тот факт, что кэши, совместимые с протоколом pre-HTTP/1.1, не соблюдают
директива максимального возраста. Другие директивы позволяют пользовательскому агенту изменять базовый срок действия.
механизм. Эти директивы МОГУТ быть указаны в запросе: Если кеш возвращает устаревший ответ либо из-за
директива по запросу, или потому что кеш настроен на
переопределить время истечения срока ответа, кэш ДОЛЖЕН прикрепить
Заголовок предупреждения к устаревшему ответу с использованием предупреждения 110 (ответ
несвежий). Кэш МОЖЕТ быть настроен на возврат устаревших ответов без
валидация, но только если это не противоречит какому-либо уровню "ОБЯЗАТЕЛЬНО"
требования, касающиеся проверки кэша (например, «обязательная повторная проверка»
директиву управления кешем). Если и новый запрос, и кешированная запись содержат «max-age»,
директивы, то меньшее из двух значений используется для определения
свежесть кэшированной записи для этого запроса. Иногда пользовательский агент может захотеть или должен настаивать на том, чтобы кеш
перепроверить свою запись в кэше на исходном сервере (а не только на
следующий кеш по пути к исходному серверу), либо перезагрузить его
запись кэша с исходного сервера. Сквозная повторная проверка может быть
необходимо, если либо кеш, либо исходный сервер переоценили
время истечения кэшированного ответа. Сквозная перезагрузка может быть
необходимо, если запись кэша по какой-либо причине была повреждена. Сквозная повторная проверка может быть запрошена либо тогда, когда клиент
не иметь собственной локальной кэшированной копии, и в этом случае мы называем ее
"неуказанная сквозная повторная проверка", или когда у клиента есть
локальная кэшированная копия, и в этом случае мы называем ее "конкретной сквозной
переаттестация». Клиент может указать эти три вида действий с помощью Cache-
Директивы запроса управления: Поле заголовка Cache-Control можно расширить за счет использования одного
или несколько маркеров расширения кеша, каждый из которых имеет необязательное назначенное значение.
Информационные расширения (те, которые не требуют изменения в
поведение кэша) МОЖЕТ быть добавлено без изменения семантики других
директивы. Поведенческие расширения предназначены для работы, действуя как
модификаторы к существующей базе директив кеша. Оба новых
поставляются директива и стандартная директива, так что
приложения, которые не понимают новую директиву, по умолчанию
к поведению, определенному стандартной директивой, и те, которые
понимать, что новая директива распознает ее как изменяющую
требования, связанные со стандартной директивой. Этим способом,
расширения директив управления кешем могут быть сделаны без
требующие внесения изменений в базовый протокол. Этот механизм расширения зависит от кэша HTTP, подчиняющегося всем
директивы управления кешем, определенные для его собственной HTTP-версии, подчиняясь
определенные расширения и игнорирование всех директив, которые он не
понять. Например, рассмотрим гипотетическую новую директиву ответа, называемую
community, который действует как модификатор частной директивы. Мы
определите эту новую директиву так, чтобы она означала, что в дополнение к любому
кеш, любой кеш, которым пользуются только члены сообщества
названный в своем значении, может кэшировать ответ. Исходный сервер
желая разрешить сообществу UCI использовать частный
ответ в их общем кэше (ах) может сделать это, включив Кэш, видящий это поле заголовка, будет действовать правильно, даже если кеш
не понимает расширение кэша сообщества, так как оно также
видеть и понимать частную директиву и, таким образом, по умолчанию использовать безопасный
поведение. Нераспознанные директивы кеша ДОЛЖНЫ игнорироваться; предполагается, что любой
cache-directive, которая, вероятно, не будет распознана кешем HTTP/1.1, будет
сочетаться со стандартными директивами (или ответом по умолчанию
возможность кэширования), чтобы поведение кэша оставалось минимальным. правильно, даже если кеш не понимает расширение(я). Поле общего заголовка Connection позволяет отправителю указать
параметры, которые желательны для этого конкретного соединения и НЕ ДОЛЖНЫ
быть переданы прокси через дальнейшие соединения. Заголовок Connection имеет следующую грамматику: Прокси-серверы HTTP/1.1 ДОЛЖНЫ анализировать поле заголовка Connection перед
сообщение пересылается и для каждого маркера соединения в этом поле
удалить все поля заголовка из сообщения с тем же именем, что и
токен соединения. Варианты подключения сигнализируются наличием
токен подключения в поле заголовка Connection, а не какой-либо
соответствующие дополнительные поля заголовка, поскольку дополнительный заголовок
поле не может быть отправлено, если нет параметров, связанных с этим
вариант подключения. Заголовки сообщений, перечисленные в заголовке Connection, НЕ ДОЛЖНЫ включать
сквозные заголовки, такие как Cache-Control. HTTP/1.1 определяет опцию «закрыть» соединение для отправителя.
сигнализировать о том, что соединение будет закрыто после завершения
отклик. Например, в полях заголовка запроса или ответа указывает, что
соединение НЕ ДОЛЖНО считаться «постоянным» (раздел 8.1)
после завершения текущего запроса/ответа. Приложения HTTP/1.1, которые не поддерживают постоянные соединения, ДОЛЖНЫ
включать опцию «закрыть» соединение в каждое сообщение. Система, получающая сообщение HTTP/1.0 (или более ранней версии), которое
ДОЛЖЕН включать заголовок Connection для каждого маркера подключения в этом
поле, удалить и игнорировать любые поля заголовка из сообщения с
то же имя, что и у токена подключения. Это защищает от ошибочного
пересылка таких полей заголовка прокси-серверами до HTTP/1. 1. См. раздел
19.6.2. Поле заголовка сущности Content-Encoding используется в качестве модификатора для
медиа-тип. Если он присутствует, его значение указывает, какой дополнительный контент
кодировки были применены к телу объекта, и, таким образом, какое декодирование
механизмы должны быть применены для того, чтобы получить медиа-тип
на который ссылается поле заголовка Content-Type. Content-Encoding
в основном используется для сжатия документа без потери
идентичность его основного типа носителя. Коды контента определены в разделе 3.5. Примером его использования является Кодирование контента является характеристикой объекта, идентифицируемого
URI запроса. Обычно тело объекта хранится с этим
кодирование и декодируется только перед рендерингом или аналогичным использованием. Однако непрозрачный прокси-сервер МОЖЕТ изменить кодировку содержимого, если
известно, что новое кодирование приемлемо для получателя, если только
В сообщении присутствует директива управления кешем "no-transform". Если кодирование содержимого объекта не является «идентичностью», то
ответ ДОЛЖЕН включать заголовок объекта Content-Encoding (раздел
14.11), в котором перечислены используемые кодировки неидентификационного контента. Если кодирование содержимого объекта в сообщении запроса не
приемлемым для исходного сервера, сервер ДОЛЖЕН ответить
код состояния 415 (неподдерживаемый тип носителя). Если к объекту было применено несколько кодировок, содержимое
Кодировки ДОЛЖНЫ быть перечислены в том порядке, в котором они были применены.
МОЖЕТ быть предоставлена дополнительная информация о параметрах кодирования.
другими полями заголовка объекта, не определенными в этой спецификации. Поле заголовка объекта Content-Language описывает естественный
язык(и) целевой аудитории для вложенного объекта. Примечание
что это может быть не эквивалентно всем языкам, используемым в
сущность-тело. Языковые теги определены в разделе 3.10. Основная цель
Content-Language позволяет пользователю идентифицировать и различать
объекты в соответствии с предпочитаемым пользователем языком. Таким образом, если
основной контент предназначен только для датской грамотной аудитории,
соответствующее поле Если Content-Language не указан, по умолчанию содержимое
предназначен для всех языковых аудиторий. Это может означать, что
отправитель не считает его специфичным для какого-либо естественного языка,
или что отправитель не знает, для какого языка оно предназначено. Несколько языков МОГУТ быть указаны для содержимого, предназначенного для
несколько аудиторий. Например, перевод «Договора о
Вайтанги», представленный одновременно на языке оригинала маори и английском языке.
версии, потребуют Однако только потому, что несколько языков присутствуют в сущности
не означает, что он предназначен для многоязычной аудитории.
Примером может служить учебник для начинающих, такой как «Первый
Урок латыни», который явно предназначен для
англоязычная аудитория. В этом случае Content-Language
правильно включать только "en". Content-Language МОЖЕТ применяться к любому типу медиа -- это не
ограничивается текстовыми документами. Поле заголовка сущности Content-Length указывает размер
сущность-тело в десятичном числе OCTET, отправленное получателю или,
в случае метода HEAD размер тела-сущности,
был бы отправлен, если бы запрос был GET. Примером является Приложения ДОЛЖНЫ использовать это поле для указания длины передачи
тело сообщения, если это не запрещено правилами раздела
4. 4. Любое значение Content-Length, большее или равное нулю, является допустимым значением.
Раздел 4.4 описывает, как определить длину тела сообщения.
если Content-Length не указан. Обратите внимание, что значение этого поля существенно отличается от
соответствующее определение в MIME, где это необязательное поле
используется в типе содержимого «message/external-body». В HTTP это
ДОЛЖНО быть отправлено всякий раз, когда длина сообщения может быть определена заранее.
быть переданы, если это не запрещено правилами в
раздел 4.4. Поле заголовка объекта Content-Location МОЖЕТ использоваться для предоставления
расположение ресурса для сущности, заключенной в сообщении, когда это
объект доступен из местоположения, отдельного от запрошенного
URI ресурса. Сервер ДОЛЖЕН предоставить Content-Location для
вариант, соответствующий объекту ответа; особенно в случае
где ресурс имеет несколько объектов, связанных с ним, и те
объекты на самом деле имеют отдельные местоположения, по которым они могут быть
при индивидуальном доступе сервер ДОЛЖЕН предоставить Content-Location
для конкретного варианта, который возвращается. Значение Content-Location также определяет базовый URI для
организация. Значение Content-Location не является заменой исходного
запрошенный URI; это только заявление о местонахождении ресурса
соответствующий этому конкретному объекту на момент запроса.
Будущие запросы МОГУТ указывать URI Content-Location в качестве запроса-
URI, если требуется определить источник этого конкретного
организация. Кэш не может предполагать, что сущность с Content-Location
отличается от URI, используемого для получения, его можно использовать для ответа на
более поздние запросы по этому URI Content-Location. Однако Содержание-
Местоположение может быть использовано для различения нескольких сущностей.
извлекается из одного запрошенного ресурса, как описано в разделе
13.6. Если Content-Location является относительным URI, относительный URI
интерпретируется относительно Request-URI. Значение заголовка Content-Location в запросах PUT или POST:
неопределенный; серверы могут игнорировать его в таких случаях. Поле заголовка сущности Content-MD5, как определено в RFC 1864 [23],
дайджест MD5 тела объекта с целью предоставления
сквозная проверка целостности сообщения (MIC) тела объекта. (Примечание: а
MIC хорош для обнаружения случайной модификации тела сущности.
в пути, но не является защитой от злонамеренных атак.) Поле заголовка Content-MD5 МОЖЕТ быть сгенерировано исходным сервером или
client для проверки целостности сущности-тела. Только
исходные серверы или клиенты МОГУТ генерировать поле заголовка Content-MD5;
прокси и шлюзы НЕ ДОЛЖНЫ генерировать его, так как это нарушит его
значение в качестве сквозной проверки целостности. Любой получатель сущности-
body, включая шлюзы и прокси, МОЖЕТ проверять, что значение дайджеста
в этом поле заголовка соответствует полученному телу объекта. Дайджест MD5 вычисляется на основе содержимого тела объекта,
включая любое кодирование контента, которое было применено, но не включая
любое кодирование передачи, применяемое к телу сообщения. Если сообщение
получено с кодировкой передачи, эта кодировка ДОЛЖНА быть удалена
перед проверкой значения 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 не разрешено в
части тела. Преобразование всех разрывов строк в CRLF НЕ ДОЛЖНО выполняться до
вычисление или проверка дайджеста: соглашение о разрыве строки, используемое в
фактически передаваемый текст ДОЛЖЕН оставаться неизменным при вычислении
дайджест. Заголовок сущности Content-Range отправляется с частичным телом сущности в
укажите, где в полном теле сущности должно быть частичное тело
применяемый. Единицы диапазона определены в разделе 3.12. В заголовке СЛЕДУЕТ указывать общую длину полного тела объекта,
если только эта длина неизвестна или ее трудно определить. звездочка
Символ «*» означает, что длина экземпляра на данный момент неизвестна.
когда был сгенерирован ответ. В отличие от значений byte-ranges-specifier (см. раздел 14.35.1), byte-ranges-specifier
range-resp-spec ДОЛЖЕН указывать только один диапазон и ДОЛЖЕН содержать
абсолютные позиции байтов как для первого, так и для последнего байта
диапазон. byte-content-range-spec с byte-range-resp-spec, последний из которых
значение byte-pos меньше, чем его значение first-byte-pos, или чье
значение длины экземпляра меньше или равно его последнему байту-позиции
значение, недействительно. Получатель недопустимого byte-content-range-
spec ДОЛЖЕН игнорировать его и любой контент, передаваемый вместе с ним. Сервер, отправляющий ответ с кодом состояния 416 (Запрошенный диапазон не
удовлетворительным) СЛЕДУЕТ включать поле Content-Range с диапазоном байтов.
соответственно спецификация "*". Длина экземпляра определяет текущую длину выбранный ресурс. Ответ с кодом состояния 206 (частичный
Content) НЕ ДОЛЖЕН включать поле Content-Range с диапазоном байтов.
соответственно спецификация "*". Примеры значений byte-content-range-spec при условии, что сущность
содержит всего 1234 байта: Когда сообщение HTTP включает в себя содержимое одного диапазона (для
например, ответ на запрос одного диапазона или на запрос
для набора диапазонов, которые перекрываются без каких-либо пробелов), это содержимое
передается с заголовком Content-Range и заголовком Content-Length
показывает количество фактически переданных байтов. Например, Когда сообщение HTTP включает в себя содержимое нескольких диапазонов (для
например, ответ на запрос нескольких непересекающихся
диапазоны), они передаются как составное сообщение. составной
тип носителя, используемый для этой цели, - "multipart/byteranges", как определено
в приложении 19.2. См. приложение 19.6.3 по вопросам совместимости. Ответ на запрос одного диапазона НЕ ДОЛЖЕН быть отправлен с использованием
тип носителя multipart/byteranges. Ответ на запрос о
несколько диапазонов, результатом которых является один диапазон, МОГУТ быть отправлены как
тип носителя multipart/byteranges с одной частью. Клиент, который не может
декодировать сообщение multipart/byteranges НЕ ДОЛЖНО запрашивать несколько
диапазоны байтов в одном запросе. Когда клиент запрашивает несколько диапазонов байтов в одном запросе,
сервер ДОЛЖЕН возвращать их в том порядке, в котором они появились в
запрос. Если сервер игнорирует спецификацию диапазона байтов, потому что она синтаксически
недействителен, сервер ДОЛЖЕН обрабатывать запрос так, как если бы недопустимый диапазон
поле заголовка не существует. (Обычно это означает вернуть 200
ответ, содержащий полную сущность). Если сервер получает запрос (кроме запроса, включающего If-
Поле заголовка запроса диапазона) с неудовлетворительным запросом диапазона
поле заголовка (то есть все значения byte-range-spec имеют
значение first-byte-pos больше, чем текущая длина выбранного
ресурс), он ДОЛЖЕН вернуть код ответа 416 (Запрошенный диапазон
невыполнимо) (раздел 10.4.17). Поле заголовка сущности Content-Type указывает тип носителя
сущность-тело, отправляемое получателю, или, в случае метода HEAD,
тип носителя, который был бы отправлен, если бы запрос был GET. Типы носителей определены в разделе 3.7. Пример поля Дальнейшее обсуждение методов определения типа носителя
сущность представлена в разделе 7.2.1. Поле общего заголовка «Дата» представляет дату и время, когда
сообщение было создано, имея ту же семантику, что и исходная дата в
RFC 822. Значением поля является HTTP-дата, как описано в разделе
3.3.1; он ДОЛЖЕН быть отправлен в формате даты RFC 1123 [8]. Примером является Исходные серверы ДОЛЖНЫ включать поле заголовка Date во все ответы,
кроме этих случаев: Полученное сообщение, не имеющее поля заголовка Date, ДОЛЖНО быть
назначается получателем, если сообщение будет кэшировано этим
получатель или шлюз через протокол, для которого требуется дата. HTTP
реализация без часов НЕ ДОЛЖНА кэшировать ответы без
перепроверять их при каждом использовании. Кэш HTTP, особенно общий
кэш, СЛЕДУЕТ использовать механизм, такой как NTP [28], для синхронизации его
часы с надежным внешним эталоном. Клиенты ДОЛЖНЫ отправлять поле заголовка Date только в сообщениях, которые включают
сущность-тело, как в случае запросов PUT и POST, и даже
тогда это необязательно. Клиент без часов НЕ ДОЛЖЕН отправлять дату
поле заголовка в запросе. HTTP-дата, отправленная в заголовке Date, НЕ ДОЛЖНА представлять дату и
время после генерации сообщения. ДОЛЖЕН представлять
наилучшее доступное приближение даты и времени сообщения
генерации, если реализация не имеет средств для генерации
достаточно точные дата и время. Теоретически дата должна быть
представляют момент непосредственно перед созданием объекта. В
на практике дата может быть сгенерирована в любой момент во время сообщения
происхождения, не затрагивая его семантической ценности. В некоторых реализациях исходного сервера часы могут отсутствовать. Исходный сервер без часов НЕ ДОЛЖЕН назначать Expires или Last-
Измененные значения для ответа, если только эти значения не были связаны
с ресурсом системой или пользователем с надежными часами. Это может
назначить известное значение Expires на сервере или до него
время конфигурации должно быть в прошлом (это позволяет
ответов без сохранения отдельных значений Expires для каждого
ресурс). Поле заголовка ответа ETag предоставляет текущее значение
тег объекта для запрошенного варианта. Заголовки, используемые с сущностью
теги описаны в разделах 14.24, 14.26 и 14.44. Тег объекта
МОЖЕТ использоваться для сравнения с другими объектами из того же ресурса.
(см. раздел 13.3.3). Примеры: Поле заголовка запроса Expect используется для указания того, что
поведение сервера требуется клиенту. Сервер, который не понимает или не может выполнить какое-либо из
ожидаемые значения в поле Expect запроса ДОЛЖНЫ ответить
с соответствующим статусом ошибки. Сервер ДОЛЖЕН ответить 417
(Ожидание не выполнено) статус, если какое-либо из ожиданий не может быть выполнено
или, если есть другие проблемы с запросом, какой-то другой 4xx
статус. Это поле заголовка определяется с помощью расширяемого синтаксиса, позволяющего
будущие расширения. Если сервер получает запрос, содержащий
Поле ожидания, которое включает в себя расширение ожидания, которого нет
поддержки, он ДОЛЖЕН ответить статусом 417 (ошибка ожидания). Сравнение значений ожидания не зависит от регистра для некавычек
токены (включая токен 100-continue) и чувствителен к регистру для
ожидание-расширения строки в кавычках. Механизм Expect является пошаговым: то есть прокси-сервер HTTP/1.1 ДОЛЖЕН
вернуть статус 417 (ошибка ожидания), если он получает запрос
с надеждой, что она не может оправдаться. Тем не менее, Ожидайте
сам заголовок запроса сквозной; он ДОЛЖЕН быть перенаправлен, если
запрос переадресован. Многие старые приложения HTTP/1.0 и HTTP/1.1 не понимают
Ожидайте заголовок. См. раздел 8.2.3 об использовании статуса 100 (продолжить). Поле заголовка объекта Expires указывает дату/время, после которого
ответ считается устаревшим. Устаревшая запись кэша обычно не может быть
возвращаемый кешем (либо кешем прокси, либо кешем пользовательского агента)
если только он не был предварительно проверен исходным сервером (или
промежуточный кеш, в котором есть свежая копия объекта). См. раздел
13.2 для дальнейшего обсуждения модели истечения срока действия. Наличие поля Expires не означает, что исходный
ресурс изменится или перестанет существовать до, или после этого
время. Формат представляет собой абсолютную дату и время, как определено HTTP-датой в
раздел 3.3.1; он ДОЛЖЕН быть в формате даты RFC 1123: Примером его использования является Клиенты и кэши HTTP/1.1 ДОЛЖНЫ обрабатывать другие недопустимые форматы даты,
особенно включая значение «0», как в прошлом (т. е. «уже
истекший"). Чтобы пометить ответ как «уже просроченный», исходный сервер отправляет
Дата истечения срока действия, равная значению заголовка Date. (см. правила
для расчетов истечения в разделе 13.2.4.) Чтобы пометить ответ как «бессрочный», исходный сервер отправляет
Истекает примерно через год с момента получения ответа. послал. Серверы HTTP/1.1 НЕ ДОЛЖНЫ отправлять даты истечения срока действия более одной
год в будущем. Наличие поля заголовка Expires со значением даты
время в будущем для ответа, который в противном случае по умолчанию был бы
non-cacheable указывает, что ответ можно кэшировать, если только
в противном случае указывается полем заголовка Cache-Control (раздел 14.9). Поле From request-header, если оно задано, ДОЛЖНО содержать Интернет
адрес электронной почты пользователя-человека, который контролирует запрашивающего пользователя
агент. Адрес ДОЛЖЕН использоваться машиной, как определено в «почтовом ящике».
в RFC 822 [9], обновленном RFC 1123 [8]: Пример: Это поле заголовка МОЖЕТ использоваться для целей регистрации и как средство для
определение источника недействительных или нежелательных запросов. НЕ ДОЛЖНО
использоваться в качестве небезопасной формы защиты доступа. Интерпретация
этого поля является то, что запрос выполняется от имени
данное лицо, которое берет на себя ответственность за выполненный метод. В
В частности, агентам роботов СЛЕДУЕТ включать этот заголовок, чтобы
с лицом, ответственным за работу робота, можно связаться, если возникнут проблемы
происходят на принимающей стороне. Адрес электронной почты в Интернете в этом поле МОЖЕТ быть отделен от
Интернет-хост, выдавший запрос. Например, при запросе
передается через прокси, исходный адрес эмитента ДОЛЖЕН быть
использовал. Клиент НЕ ДОЛЖЕН отправлять поле заголовка From без указания пользователя.
одобрение, так как это может противоречить интересам конфиденциальности пользователя или
политика безопасности их сайта. Настоятельно рекомендуется, чтобы
пользователь может отключать, включать и изменять значение этого поля
в любое время до запроса. Поле заголовка запроса Host указывает хост и порт Интернета.
номер запрашиваемого ресурса, полученный из оригинала
URI, предоставленный пользователем или ссылающимся ресурсом (обычно URL-адрес HTTP, как описано в разделе 3.2.2). Значение поля Host ДОЛЖНО представлять
полномочия по именованию исходного сервера или шлюза, предоставленные
исходный URL. Это позволяет исходному серверу или шлюзу
различать внутренне неоднозначные URL-адреса, такие как корень "/"
URL-адрес сервера для нескольких имен хостов на одном IP-адресе. «Хост» без какой-либо информации о завершающем порте подразумевает значение по умолчанию.
порт для запрошенной службы (например, «80» для URL-адреса HTTP). За
например, запрос на исходный сервер для Клиент ДОЛЖЕН включать поле заголовка Host во все запросы HTTP/1.1.
Сообщения . Если запрошенный URI не включает интернет-хост
имя запрашиваемой службы, то поле заголовка Host ДОЛЖНО
быть задано с пустым значением. Прокси-сервер HTTP/1.1 ДОЛЖЕН гарантировать, что любой
сообщение запроса, которое он пересылает, содержит соответствующий заголовок хоста
поле, которое идентифицирует услугу, запрошенную прокси. Все
Интернет-серверы HTTP/1.1 ДОЛЖНЫ отвечать кодом 400 (неверный запрос).
код состояния для любого сообщения запроса HTTP/1.1, в котором отсутствует заголовок узла
поле. См. разделы 5.2 и 19.6.1.1 для других требований, касающихся
Хозяин. Поле заголовка запроса If-Match используется с методом, чтобы сделать его
условный. Клиент, который ранее имел одну или несколько сущностей
полученный из ресурса, может проверить, что один из этих объектов
текущий, включив список связанных с ними тегов сущностей в
Поле заголовка If-Match. Теги объектов определены в разделе 3.11.
целью этой функции является обеспечение эффективного обновления кэшированных
информацию с минимальным объемом транзакционных накладных расходов. Это также
используется при обновлении запросов, чтобы предотвратить непреднамеренное изменение
неправильная версия ресурса. Как частный случай, значение "*"
соответствует любой текущей сущности ресурса. Если какой-либо из тегов объекта совпадает с тегом объекта, который
был бы возвращен в ответ на аналогичный запрос GET
(без заголовка If-Match) на этом ресурсе или если указано "*" и любой текущий объект существует для этого ресурса, то сервер МОЖЕТ
выполнить запрошенный метод, как если бы поле заголовка If-Match не
существует. Сервер ДОЛЖЕН использовать функцию строгого сравнения (см. раздел 13.3.3).
для сравнения тегов сущностей в If-Match. Если ни один из тегов объекта не соответствует или если задано «*» и нет текущего
объект существует, сервер НЕ ДОЛЖЕН выполнять запрошенный метод, и
ДОЛЖЕН вернуть ответ 412 (ошибка предварительного условия). Это поведение
наиболее полезно, когда клиент хочет предотвратить метод обновления, например
как PUT, от изменения ресурса, который изменился с тех пор, как клиент
последний раз извлекал. Если запрос без поля заголовка If-Match приведет к
ничего, кроме статуса 2xx или 412, то заголовок If-Match
ДОЛЖЕН быть проигнорирован. Смысл «If-Match: *» в том, что метод ДОЛЖЕН быть выполнен
если представление, выбранное исходным сервером (или кэшем,
возможно, с использованием механизма Vary, см. раздел 14.44), и
НЕ ДОЛЖЕН выполняться, если представление не существует. Запрос, предназначенный для обновления ресурса (например, PUT), МОЖЕТ включать
Поле заголовка If-Match, чтобы указать, что метод запроса НЕ ДОЛЖЕН быть
применяется, если сущность, соответствующая значению If-Match (одиночное
тэг объекта) больше не является представлением этого ресурса. Этот
позволяет пользователю указать, что он не желает, чтобы запрос
успешно, если ресурс был изменен без их ведома. Примеры: Результат запроса, имеющего как поле заголовка If-Match, так и
либо поле заголовка If-None-Match, либо поле If-Modified-Since.
не определено этой спецификацией. Поле заголовка запроса If-Modified-Since используется с методом для
сделать его условным: если запрошенный вариант не был изменен
с момента, указанного в этом поле, сущность не будет
возвращено с сервера; вместо этого ответ 304 (не измененный) будет
возвращаться без какого-либо тела сообщения. Пример поля: Метод GET с заголовком If-Modified-Since и без заголовка Range.
запрашивает, чтобы идентифицированный объект был передан только в том случае, если он
был изменен с даты, указанной в заголовке If-Modified-Since. Алгоритм определения этого включает следующие случаи: Цель этой функции — разрешить эффективное обновление кэшированных
информацию с минимальным объемом транзакционных накладных расходов. Результат запроса, имеющего как поле заголовка If-Modified-Since,
и поля заголовка If-Match или If-Unmodified-Since
не определено этой спецификацией. Поле заголовка запроса If-None-Match используется с методом для создания
это условно. Клиент, который ранее имел одну или несколько сущностей
полученный из ресурса, может проверить, что ни один из этих объектов не
текущий, включив список связанных с ними тегов сущностей в
Поле заголовка If-None-Match. Цель этой функции состоит в том, чтобы позволить
эффективное обновление кэшированной информации с минимальным объемом
транзакционные накладные расходы. Он также используется для предотвращения метода (например, PUT)
от непреднамеренного изменения существующего ресурса, когда клиент
считает, что ресурса не существует. Как особый случай, значение "*" соответствует любому текущему объекту
ресурс. Если какой-либо из тегов объекта совпадает с тегом объекта, который
был бы возвращен в ответ на аналогичный запрос GET
(без заголовка If-None-Match) на этом ресурсе или если "*"
данный и любая текущая сущность существует для этого ресурса, то
сервер НЕ ДОЛЖЕН выполнять запрошенный метод, если только это не требуется
так как дата модификации ресурса не соответствует этой
предоставляется в поле заголовка If-Modified-Since в запросе.
Вместо этого, если метод запроса был GET или HEAD, сервер ДОЛЖЕН
ответить ответом 304 (не изменено), включая кеш-
связанные поля заголовка (в частности, ETag) одного из объектов, которые
совпало. Для всех других методов запроса сервер ДОЛЖЕН ответить
статус 412 (сбой предварительного условия). См. раздел 13.3.3 для правил о том, как определить, являются ли теги двух сущностей
соответствие. Функция слабого сравнения может использоваться только с GET или HEAD.
Запросы. Если ни один из тегов сущности не совпадает, сервер МОЖЕТ выполнить
запрошенный метод, как если бы поле заголовка If-None-Match не существовало,
но ДОЛЖНЫ также игнорировать любые поля заголовка If-Modified-Since в
запрос. То есть, если никакие теги сущностей не совпадают, сервер НЕ ДОЛЖЕН
вернуть ответ 304 (не изменено). Если запрос будет без поля заголовка If-None-Match, результат
в любом другом статусе, кроме 2xx или 304, то If-None-Match
заголовок ДОЛЖЕН игнорироваться. (См. раздел 13.3.4 для обсуждения
поведение сервера, когда появляются и If-Modified-Since, и If-None-Match
в том же запросе) Значение «If-None-Match: *» в том, что метод НЕ ДОЛЖЕН быть
выполняется, если представление, выбранное исходным сервером (или
кэш, возможно, с использованием механизма Vary, см. раздел 14.44)
существует, и СЛЕДУЕТ выполняться, если представление не существует. Эта функция предназначена для предотвращения гонок между PUT.
операции. Примеры: Результат запроса, имеющего как поле заголовка If-None-Match, так и
либо поле заголовка If-Match, либо поле заголовка If-Unmodified-Since.
не определено этой спецификацией. Если у клиента есть частичная копия объекта в его кеше, и он желает
чтобы иметь актуальную копию всего объекта в своем кеше, он
можно использовать заголовок запроса Range с условным GET (используя
один или оба из If-Unmodified-Since и If-Match.) Однако, если
условие не выполняется, потому что сущность была изменена, клиент
затем придется сделать второй запрос, чтобы получить весь текущий
сущность-тело. Заголовок If-Range позволяет клиенту «замкнуть» второй
запрос. Неформально это означает: «если объект не изменился, отправить
мне часть (части), которые мне не хватает; в противном случае пришлите мне весь новый
организация'. Если у клиента нет тега сущности для сущности, но есть Last-
Дата изменения, МОЖЕТ использовать эту дату в заголовке If-Range. (
сервер может различать допустимую дату HTTP и любую форму
entity-tag, проверив не более двух символов.) If-Range
заголовок СЛЕДУЕТ использовать только вместе с заголовком Range и ДОЛЖЕН быть
игнорируется, если запрос не включает заголовок Range или если
сервер не поддерживает операцию поддиапазона. Если тег объекта, указанный в заголовке If-Range, соответствует текущему
тэг объекта для объекта, то сервер ДОЛЖЕН предоставить
указанный поддиапазон объекта с использованием 206 (частичное содержимое)
отклик. Если тег объекта не совпадает, то сервер ДОЛЖЕН
вернуть весь объект, используя ответ 200 (ОК). Поле заголовка запроса If-Unmodified-Since используется с методом для
сделать его условным. Если запрошенный ресурс не был изменен
с момента, указанного в этом поле, сервер ДОЛЖЕН выполнить
запрошенная операция, как если бы заголовок If-Unmodified-Since не был
подарок. Если запрошенный вариант был изменен с указанного времени,
сервер НЕ ДОЛЖЕН выполнять запрошенную операцию и ДОЛЖЕН возвращать
412 (сбой предварительного условия). Пример поля: Если запрос нормальный (т.е. без If-Unmodified-Since
заголовок) приведет к чему-то другому, кроме статуса 2xx или 412,
Заголовок If-Unmodified-Since ДОЛЖЕН игнорироваться. Если указанная дата недействительна, заголовок игнорируется. Результат запроса с заголовком If-Unmodified-Since
поле и заголовок If-None-Match или If-Modified-Since
fields не определено этой спецификацией. Поле заголовка объекта Last-Modified указывает дату и время
который исходный сервер считает, что вариант был последним изменен. Примером его использования является Точное значение этого поля заголовка зависит от реализации.
исходного сервера и характера исходного ресурса. За
файлы, это может быть просто время последнего изменения файловой системы. За
сущности с динамически включенными частями, это может быть самая последняя
набора времени последнего изменения для его составных частей. Для базы данных
шлюзов, это может быть отметка времени последнего обновления записи. За
виртуальных объектов, это может быть последний раз, когда внутреннее состояние изменилось. Исходный сервер НЕ ДОЛЖЕН отправлять дату последнего изменения, которая является более поздней.
чем время отправки сообщения сервером. В таких случаях, когда
последняя модификация ресурса указывала бы на какое-то время в
будущем сервер ДОЛЖЕН заменить эту дату сообщением
дата возникновения. Исходный сервер ДОЛЖЕН получить значение Last-Modified объекта
как можно ближе ко времени, когда он генерирует значение Date для
его ответ. Это позволяет получателю сделать точную оценку
времени модификации объекта, особенно если объект изменяется
рядом с моментом генерации ответа. Серверы HTTP/1.1 ДОЛЖНЫ отправлять Last-Modified всякий раз, когда это возможно. Поле заголовка ответа Location используется для перенаправления получателя
в место, отличное от Request-URI для завершения
запрос или идентификация нового ресурса. Для 201 (Создано)
ответы, это местоположение нового ресурса, который был создан
по запросу. Для ответов 3xx местоположение ДОЛЖНО указывать
предпочтительный URI сервера для автоматического перенаправления на ресурс.
значение поля состоит из одного абсолютного URI. Пример: Поле заголовка запроса Max-Forwards предоставляет механизм с
TRACE (раздел 9.8) и OPTIONS (раздел 9. 2) для ограничения
количество прокси или шлюзов, которые могут перенаправить запрос на
следующий входящий сервер. Это может быть полезно, когда клиент пытается
чтобы отследить цепочку запросов, которая, кажется, терпит неудачу или зацикливается
средняя цепь. Значение Max-Forwards представляет собой десятичное целое число, указывающее оставшееся
сколько раз это сообщение запроса может быть перенаправлено. Каждый получатель прокси или шлюза запроса TRACE или OPTIONS
содержащее поле заголовка Max-Forwards, ДОЛЖНО проверять и обновлять его
значение до пересылки запроса. Если полученное значение равно нулю
(0) получатель НЕ ДОЛЖЕН пересылать запрос; вместо этого он ДОЛЖЕН
ответить как конечный получатель. Если полученное значение Max-Forwards равно
больше нуля, то пересылаемое сообщение ДОЛЖНО содержать обновленный
Поле Max-Forwards со значением, уменьшенным на единицу (1). Поле заголовка Max-Forwards МОЖЕТ игнорироваться для всех остальных методов.
определенных этой спецификацией и для любых методов расширения, для которых
он явно не упоминается как часть определения этого метода. Поле общего заголовка Pragma используется для включения
конкретные директивы, которые могут применяться к любому получателю на протяжении
цепочка запросов/ответов. Все директивы прагмы указывают необязательный
поведение с точки зрения протокола; однако некоторые системы
МОЖЕТ требовать, чтобы поведение соответствовало директивам. Когда директива no-cache присутствует в сообщении запроса,
приложение ДОЛЖНО пересылать запрос исходному серверу даже
если у него есть кешированная копия того, что запрашивается. Эта прагма
директива имеет ту же семантику, что и директива кэша no-cache (см.
раздел 14.9) и определен здесь для обратной совместимости с
HTTP/1.0. Клиенты ДОЛЖНЫ включать оба поля заголовка, если нет кэша.
запрос отправляется на сервер, о котором не известно, что он совместим с HTTP/1.1. Директивы Pragma ДОЛЖНЫ передаваться через прокси или шлюз
приложение, независимо от их значимости для этого приложения,
поскольку директивы могут быть применимы ко всем получателям на
цепочка запросов/ответов. Невозможно указать прагму для
конкретный получатель; однако любая директива прагмы, не относящаяся к
получатель ДОЛЖЕН игнорироваться этим получателем. Кэши HTTP/1.1 ДОЛЖНЫ обрабатывать «Pragma: no-cache», как если бы клиент
отправил «Кэш-Контроль: нет кеша». Никаких новых директив Pragma не будет.
определено в HTTP. Поле заголовка ответа Proxy-Authenticate ДОЛЖНО быть включено как часть
ответа 407 (требуется аутентификация прокси-сервера). Значение поля
состоит из вызова, указывающего схему аутентификации и
параметры, применимые к прокси для этого Request-URI. Процесс аутентификации доступа HTTP описан в разделе "HTTP
Аутентификация: базовая и дайджест-аутентификация доступа» [43]. В отличие от
WWW-Authenticate, поле заголовка Proxy-Authenticate применяется только к
текущее соединение и НЕ ДОЛЖНО передаваться вниз по течению
клиенты. Однако промежуточному прокси-серверу может потребоваться получить собственный
учетные данные, запрашивая их у нижестоящего клиента, который в
некоторые обстоятельства будут выглядеть так, как будто прокси-сервер пересылает
Поле заголовка Proxy-Authenticate. Поле заголовка запроса Proxy-Authorization позволяет клиенту
идентифицировать себя (или своего пользователя) для прокси-сервера, который требует
аутентификация. Значение поля Proxy-Authorization состоит из
учетные данные, содержащие информацию об аутентификации пользователя
агент для прокси и/или области запрашиваемого ресурса. Процесс аутентификации доступа HTTP описан в разделе "HTTP
Аутентификация: базовая и дайджест-аутентификация доступа» [43]. В отличие от
Authorization, поле заголовка Proxy-Authorization относится только к
следующий исходящий прокси-сервер, который требовал аутентификации с использованием прокси-сервера.
Поле аутентификации. Когда несколько прокси используются в цепочке, Поле заголовка Proxy-Authorization используется первым исходящим
прокси, который ожидал получить учетные данные. Прокси МОЖЕТ ретранслировать
учетные данные от клиентского запроса к следующему прокси-серверу, если это
механизм, с помощью которого прокси совместно аутентифицируют данный
запрос. Поскольку все объекты HTTP представлены в сообщениях HTTP в виде последовательностей
байтов, понятие диапазона байтов имеет смысл для любого HTTP
организация. (Однако не все клиенты и серверы должны поддерживать байт-код.
диапазонные операции.) Спецификации диапазона байтов в HTTP применяются к последовательности байтов в
тело объекта (не обязательно такое же, как тело сообщения). Операция диапазона байтов МОЖЕТ указывать один диапазон байтов или набор
диапазонов внутри одного объекта. Значение first-byte-pos в byte-range-spec дает смещение байта. первого байта в диапазоне. Значение last-byte-pos дает
byte-offset последнего байта в диапазоне; то есть байт
указанные позиции являются включительно. Байтовые смещения начинаются с нуля. Если присутствует значение last-byte-pos, оно ДОЛЖНО быть больше или
равно первому байту-позиции в этой спецификации байт-диапазона или байту-
range-spec синтаксически недействителен. Получатель диапазона байтов-
набор, включающий одну или несколько синтаксически недопустимых спецификаций диапазона байтов
значения ДОЛЖНЫ игнорировать поле заголовка, которое включает этот диапазон байтов.
установлен. Если значение last-byte-pos отсутствует или если значение больше
или равна текущей длине тела сущности, last-byte-pos
принимается равным на единицу меньше, чем текущая длина сущности-
тело в байтах. Выбрав last-byte-pos, клиент может ограничить количество
байтов, полученных без знания размера объекта. Suffix-byte-range-spec используется для указания суффикса
сущность-тело, длина которой определяется значением длины суффикса. (То есть,
эта форма определяет последние N байтов тела сущности.) Если
сущность короче указанной длины суффикса, весь
используется сущность-тело. Если синтаксически допустимый набор диапазонов байтов включает хотя бы один
range-spec, первый байт-pos которого меньше текущей длины
тело объекта или, по крайней мере, один suffix-byte-range-spec с не-
нулевая длина суффикса, то набор диапазонов байтов выполним.
В противном случае набор диапазонов байтов неудовлетворителен. Если набор диапазонов байтов
является неудовлетворительным, сервер ДОЛЖЕН вернуть ответ со статусом
из 416 (запрашиваемый диапазон не удовлетворяется). В противном случае сервер
СЛЕДУЕТ вернуть ответ со статусом 206 (Частичное содержимое)
содержащий допустимые диапазоны тела сущности. Примеры значений спецификатора диапазонов байтов (при условии, что тело объекта
длина 10000): HTTP-запросы на поиск с использованием условного или безусловного GET
методы МОГУТ запрашивать один или несколько поддиапазонов объекта вместо
весь объект, используя заголовок запроса Range, который применяется к
сущность, возвращенная в результате запроса: Сервер МОЖЕТ игнорировать заголовок Range. Однако происхождение HTTP/1.1
серверы и промежуточные кэши должны поддерживать диапазоны байтов, когда
возможно, так как Range поддерживает эффективное восстановление после частичного
неудачные передачи и поддерживает эффективное частичное извлечение больших
сущности. Если сервер поддерживает заголовок Range и указанный диапазон или
диапазоны подходят для сущности: В некоторых случаях может быть более подходящим использовать If-Range.
заголовок (см. раздел 14.27) в дополнение к заголовку Range. Если прокси, поддерживающий диапазоны, получает запрос диапазона, пересылает
запрос на входящий сервер и получает весь объект в
ответ, он ДОЛЖЕН возвращать своему клиенту только запрошенный диапазон. Это
СЛЕДУЕТ хранить весь полученный ответ в своем кеше, если это
в соответствии с его политиками распределения кеша. Поле заголовка запроса Referer[sic] позволяет клиенту указать,
для сервера адрес (URI) ресурса из
который был получен Request-URI («реферер», хотя
в поле заголовка написана ошибка. ) Заголовок запроса Referer позволяет
сервер для генерации списков обратных ссылок на интересующие ресурсы,
ведение журнала, оптимизированное кэширование и т. д. Это также позволяет
ссылки для обслуживания. Поле Referer НЕ ДОЛЖНО быть
отправляется, если Request-URI был получен из источника, не имеющего
свой собственный URI, например ввод с пользовательской клавиатуры. Пример: Если значение поля является относительным URI, его СЛЕДУЕТ интерпретировать
относительно Request-URI. URI НЕ ДОЛЖЕН включать фрагмент. Видеть
раздел 15.1.3 по соображениям безопасности. Поле заголовка ответа Retry-After можно использовать с кодом 503 (Service
Недоступно) ответ, чтобы указать, как долго ожидается, что услуга
быть недоступным для запрашивающего клиента. Это поле МОЖЕТ также использоваться
с любым ответом 3xx (перенаправление), чтобы указать минимальное время, в течение которого
агенту пользователя предлагается подождать, прежде чем выдавать перенаправленный запрос.
значение этого поля может быть как HTTP-датой, так и целым числом
секунд (в десятичном формате) после времени ответа. Два примера его использования: В последнем примере задержка составляет 2 минуты. Поле заголовка ответа сервера содержит информацию о
программное обеспечение, используемое исходным сервером для обработки запроса. Поле
может содержать несколько токенов продукта (раздел 3.8) и комментарии
идентификация сервера и любых важных подпродуктов. Продукт
жетоны перечислены в порядке их значимости для идентификации
заявление. Пример: Если ответ пересылается через прокси, прокси
приложение НЕ ДОЛЖНО изменять заголовок ответа сервера. Вместо этого это
СЛЕДУЕТ включать поле Via (как описано в разделе 14.45). Поле заголовка запроса TE указывает, какое кодирование передачи расширения
он готов принять в ответ и независимо от того, является ли он
готов принять поля трейлера в кодировании передачи по частям. Его
значение может состоять из ключевого слова "трейлеры" и/или через запятую
список имен кодирования передачи расширений с необязательным принятием
параметры (как описано в разделе 3. 6). Наличие ключевого слова «трейлеры» говорит о том, что клиент
готов принять поля трейлера в кодировании передачи по частям, как
определено в разделе 3.6.1. Это ключевое слово зарезервировано для использования с
значений переносного кодирования, даже если оно само по себе не представляет собой
передача-кодирование. Примеры его использования: Поле заголовка TE применяется только к непосредственному соединению.
Следовательно, ключевое слово ДОЛЖНО быть указано в заголовке Connection.
поле (раздел 14.10) всякий раз, когда TE присутствует в сообщении HTTP/1.1. Сервер проверяет, допустимо ли кодирование передачи в соответствии с
поле TE, используя следующие правила: Если значение поля TE пусто или если поле TE отсутствует, единственное
кодирование передачи «разделено». Сообщение без кодирования передачи
всегда приемлемо. Значение поля Trailer general указывает, что данный набор
поля заголовка присутствуют в трейлере сообщения, закодированного с помощью
фрагментированное кодирование передачи. Сообщению HTTP/1.1 СЛЕДУЕТ включать поле заголовка Trailer в
сообщение с использованием фрагментированного кодирования передачи с непустым трейлером. Делает
таким образом позволяет получателю узнать, какие поля заголовка ожидать в
трейлер. Если поле заголовка Trailer отсутствует, трейлер НЕ ДОЛЖЕН включать
любые поля заголовка. См. раздел 3.6.1 для ограничений на использование
концевые поля в "фрагментированном" кодировании передачи. Поля заголовка сообщения, перечисленные в поле заголовка Trailer, НЕ ДОЛЖНЫ
включать следующие поля заголовка: Поле общего заголовка Transfer-Encoding указывает, что (если есть)
тип преобразования был применен к телу сообщения, чтобы
безопасно передать его между отправителем и получателем. Этот
отличается от кодирования контента тем, что кодирование передачи представляет собой
свойство сообщения, а не сущности. Кодирование передачи определено в разделе 3.6. Пример: Если к объекту было применено несколько кодировок,
Кодировки ДОЛЖНЫ быть перечислены в том порядке, в котором они были применены.
МОЖЕТ быть предоставлена дополнительная информация о параметрах кодирования. другими полями заголовка объекта, не определенными в этой спецификации. Многие старые приложения HTTP/1.0 не понимают механизм передачи.
Заголовок кодировки. Общий заголовок Upgrade позволяет клиенту указать, что
дополнительные протоколы связи, которые он поддерживает и хотел бы использовать
если сервер сочтет целесообразным переключить протоколы. Сервер
НЕОБХОДИМО использовать поле заголовка Upgrade в сообщении 101 (Switching Protocols).
ответ, чтобы указать, какой протокол(ы) переключается. Например, Поле заголовка Upgrade предназначено для предоставления простого механизма
для перехода с HTTP/1.1 на какой-то другой, несовместимый протокол. Это
делает это, позволяя клиенту объявить о своем желании использовать другой
протокол, такой как более поздняя версия HTTP с более высокой основной версией
номер, даже если текущий запрос был сделан с использованием HTTP/1. 1.
Это облегчает трудный переход между несовместимыми протоколами за счет
позволяя клиенту инициировать запрос в более обычном
поддерживаемый протокол, указывая при этом серверу, что он хотел бы
использовать «лучший» протокол, если он доступен (где «лучший» определяется
сервером, возможно, в зависимости от характера метода и/или
запрашиваемый ресурс). Поле заголовка Upgrade применяется только к переключению прикладного уровня.
протоколы при существующем соединении транспортного уровня. Обновление
нельзя использовать, чтобы настаивать на изменении протокола; его принятие и использование
сервером не является обязательным. Возможности и характер
связь на уровне приложений после того, как изменение протокола полностью
зависит от выбранного нового протокола, хотя первое действие
после изменения протокола ДОЛЖЕН быть ответ на начальный HTTP
запрос, содержащий поле заголовка Upgrade. Поле заголовка Upgrade применяется только к непосредственному соединению. Следовательно, ключевое слово upgrade ДОЛЖНО быть указано в сообщении Connection.
поле заголовка (раздел 14.10) всякий раз, когда Upgrade присутствует в
Сообщение HTTP/1.1. Поле заголовка Upgrade нельзя использовать для указания перехода на
протокол по другому соединению. Для этой цели более
целесообразно использовать ответ перенаправления 301, 302, 303 или 305. Эта спецификация определяет только имя протокола "HTTP" для использования
семейство протоколов передачи гипертекста, как определено HTTP
правила версии раздела 3.1 и будущие обновления этого
Технические характеристики. В качестве имени протокола можно использовать любой токен; однако это
будет полезен только в том случае, если и клиент, и сервер связывают имя
с тем же протоколом. Поле заголовка запроса User-Agent содержит информацию о
пользовательский агент, инициирующий запрос. Это для статистических целей,
отслеживание нарушений протокола и автоматическое распознавание пользовательских
агенты ради адаптации ответов, чтобы избежать конкретного пользователя
агентские ограничения. Пользовательские агенты ДОЛЖНЫ включать это поле с
Запросы. Поле может содержать несколько токенов продукта (раздел 3.8).
и комментарии, идентифицирующие агента и любые подпродукты, которые формируют
значительную часть пользовательского агента. По соглашению, токены продукта
перечислены в порядке их значимости для идентификации
заявление. Пример: Значение поля Vary указывает набор полей заголовка запроса, которые
полностью определяет, пока ответ свежий, есть ли кеш
разрешено использовать ответ для ответа на последующий запрос
без переаттестации. Для некэшируемых или устаревших ответов функция Vary
значение поля сообщает пользовательскому агенту об использованных критериях
для выбора представления. Значение поля Vary, равное "*", означает, что
кэш не может определить из заголовков запроса последующего
запросить, является ли этот ответ подходящим представлением. Видеть
раздел 13.6 для использования поля заголовка Vary кэшами. Серверу HTTP/1.1 СЛЕДУЕТ включать поле заголовка Vary с любым
кэшируемый ответ, который подлежит согласованию с сервером.
Это позволяет кешу правильно интерпретировать будущие запросы на этом
ресурса и информирует пользовательский агент о наличии согласования на том ресурсе. Сервер МОЖЕТ включать поле заголовка Vary с
некэшируемый ответ, который подлежит согласованию с сервером,
поскольку это может предоставить пользовательскому агенту полезную информацию о
размеры, по которым отклик изменяется во время
отклик. Значение поля Vary, состоящее из списка имен полей, сигнализирует о том, что
представление, выбранное для ответа, основано на выборе
алгоритм, который учитывает ТОЛЬКО перечисленные значения полей заголовка запроса
в выборе наиболее подходящего представления. Кэш МОЖЕТ предполагать
что такой же выбор будет сделан для будущих запросов с
те же значения для перечисленных имен полей, в течение времени для
что ответ свежий. Приведенные имена полей не ограничиваются набором стандартных
поля заголовка запроса, определенные этой спецификацией. Имена полей
без учета регистра. Значение поля Vary, равное "*", сигнализирует о том, что неуказанные параметры не
ограничивается заголовками запроса (например, сетевым адресом
клиент), играют роль в выборе представления ответа.
Значение «*» НЕ ДОЛЖНО генерироваться прокси-сервером; это может быть только
генерируется исходным сервером. Поле общего заголовка Via ДОЛЖНО использоваться шлюзами и прокси для
указать промежуточные протоколы и получателей между пользователем
агентом и сервером по запросам, а также между исходным сервером и
клиент по отзывам. Аналог поля «Получено»
RFC 822 [9] и предназначен для отслеживания пересылки сообщений,
избегая циклов запросов и определяя возможности протокола
все отправители по цепочке запрос/ответ. Полученный протокол указывает версию протокола сообщения. полученные сервером или клиентом по каждому сегменту
цепочка запросов/ответов. Версия полученного протокола добавляется к
значение поля Via при пересылке сообщения, чтобы информация
о возможностях протокола вышестоящих приложений остается
видны всем получателям. Имя протокола является необязательным тогда и только тогда, когда это будет «HTTP».
поле «получено по» обычно представляет собой хост и необязательный номер порта
сервер-получатель или клиент, который впоследствии переслал сообщение.
Однако, если реальный хост считается конфиденциальной информацией,
он МОЖЕТ быть заменен псевдонимом. Если порт не указан, он МОЖЕТ
предполагается, что он является портом по умолчанию для полученного протокола. Несколько значений поля Via представляют каждый прокси или шлюз,
переслал сообщение. Каждый получатель ДОЛЖЕН добавить свою информацию
таким образом, что конечный результат упорядочен в соответствии с последовательностью
переадресация заявок. Комментарии МОГУТ использоваться в поле заголовка Via для идентификации программного обеспечения.
прокси-сервера или шлюза получателя, аналогичный User-Agent и
Поля заголовка сервера. Однако все комментарии в поле Via
необязательный и МОЖЕТ быть удален любым получателем до пересылки
сообщение. Например, сообщение запроса может быть отправлено пользователем HTTP/1.0.
агента к внутреннему прокси-серверу под кодовым названием «fred», который использует HTTP/1.1 для
перенаправить запрос на общедоступный прокси на nowhere.com, что завершает
запрос, перенаправив его на исходный сервер по адресу www.ics.uci.edu.
Запрос, полученный www.ics.uci.edu, будет иметь следующий вид:
Через поле заголовка: Прокси и шлюзы, используемые в качестве портала через сетевой брандмауэр
НЕ ДОЛЖНО по умолчанию перенаправлять имена и порты хостов в
область брандмауэра. Эту информацию СЛЕДУЕТ распространять только в том случае, если
явно включен. Если не включено, полученный хост любого хоста
за брандмауэром СЛЕДУЕТ заменить соответствующим псевдонимом
для этого хоста. Для организаций, предъявляющих строгие требования к конфиденциальности для сокрытия
внутренние структуры, прокси МОЖЕТ комбинировать упорядоченную подпоследовательность
Через записи полей заголовка с идентичными значениями полученного протокола в
единственная такая запись. Например, Приложения НЕ ДОЛЖНЫ объединять несколько записей, если они не все
под тем же организационным контролем и хосты уже были
заменены псевдонимами. Приложения НЕ ДОЛЖНЫ объединять записи, которые
имеют разные значения протокола приема. Поле общего заголовка Warning используется для переноса дополнительных
информацию о статусе или преобразовании сообщения, которое
может не отразиться в сообщении. Эта информация обычно
используется для предупреждения о возможном недостатке семантической прозрачности от
кэширование операций или преобразований, применяемых к телу сущности
сообщение. Заголовки предупреждений отправляются с ответами, используя: Ответ МОЖЕТ содержать более одного заголовка предупреждения. Предупреждающий текст ДОЛЖЕН быть на естественном языке и с набором символов,
скорее всего, будет понятен пользователю-человеку, получающему
отклик. Это решение МОЖЕТ быть основано на любых доступных знаниях, таких как
в качестве расположения кеша или пользователя, поле Accept-Language в
запрос, поле Content-Language в ответе и т. д. По умолчанию
язык — английский, а набор символов по умолчанию — ISO-8859.-1. Если используется набор символов, отличный от ISO-8859-1, он ДОЛЖЕН быть закодирован
в тексте предупреждения с использованием метода, описанного в RFC 2047 [14]. Заголовки предупреждений, как правило, могут быть применены к любому сообщению, однако
некоторые специальные коды предупреждений относятся к кэшам и могут быть
применяется к ответным сообщениям. ДОЛЖНЫ быть добавлены новые заголовки предупреждений
после любых существующих заголовков Warning. Кэш НЕ ДОЛЖЕН удалять какие-либо
Заголовок предупреждения, полученный вместе с сообщением. Однако, если кеш
успешно проверяет запись в кэше, он ДОЛЖЕН удалить все предупреждения
заголовки, ранее прикрепленные к этой записи, за исключением случаев, указанных для специальные коды предупреждений. Затем он ДОЛЖЕН добавить любые полученные заголовки предупреждений.
в подтверждающем ответе. Другими словами, заголовки Warning — это те
который будет приложен к самому последнему соответствующему ответу. Если к ответу прикреплено несколько заголовков Warning, пользователь
агент должен информировать пользователя о как можно большем количестве из них, в
порядок их появления в ответе. Если нет возможности
информировать пользователя обо всех предупреждениях, пользовательский агент ДОЛЖЕН следовать
эти эвристики: Системы, которые генерируют несколько заголовков Warning, ДОЛЖНЫ упорядочивать их с помощью
это поведение пользовательского агента в виду. Требования к поведению кэшей по отношению к Предупреждениям
указано в разделе 13.1.2. Это список определенных в настоящее время кодов предупреждений, каждый из которых имеет
рекомендуемый предупреждающий текст на английском языке и описание его значения. 110 Ответ устарел
ДОЛЖЕН быть включен всякий раз, когда возвращаемый ответ устарел. 111 Повторная проверка не удалась
ДОЛЖЕН быть включен, если кеш возвращает устаревший ответ из-за
попытка перепроверить ответ не удалась из-за невозможности
добраться до сервера. 112 Отключенная операция
ДОЛЖЕН быть включен, если кеш намеренно отключен от
остальной части сети в течение определенного периода времени. 113 Эвристическое истечение
ДОЛЖЕН быть включен, если кеш эвристически выбрал свежесть
время жизни больше 24 часов и возраст ответа больше
чем 24 часа. 199 Разное предупреждение
Текст предупреждения МОЖЕТ включать произвольную информацию, которая должна быть представлена
пользователю-человеку или зарегистрированному. Система, получившая это предупреждение, ДОЛЖНА
НЕ предпринимайте никаких автоматических действий, кроме выдачи предупреждения
Пользователь. 214 Преобразование применено
ДОЛЖЕН быть добавлен промежуточным кешем или прокси, если он применяется
преобразование, изменяющее кодировку содержимого (как указано в
заголовок Content-Encoding) или тип носителя (как указано в
заголовок Content-Type) ответа или тело объекта
ответ, если этот код предупреждения уже не появляется в ответе. 299 Разное постоянное предупреждение
Текст предупреждения МОЖЕТ включать произвольную информацию, которая должна быть представлена
пользователю-человеку или зарегистрированному. Система, получившая это предупреждение, ДОЛЖНА
НЕ предпринимайте никаких автоматических действий. Если реализация отправляет сообщение с одним или несколькими заголовками Warning
чья версия HTTP/1.0 или ниже, то отправитель ДОЛЖЕН включить в
каждое значение предупреждения — дата предупреждения, совпадающая с датой в ответе. Если реализация получает сообщение со значением предупреждения, которое
включает дату предупреждения, и эта дата предупреждения отличается от даты
значение в ответе, то это значение предупреждения ДОЛЖНО быть удалено из
сообщение перед его сохранением, пересылкой или использованием. (Это предотвращает
плохие последствия наивного кэширования полей заголовка Warning.) Если все
из значений предупреждения удаляются по этой причине, заголовок Предупреждение
ДОЛЖНЫ быть также удалены. Поле заголовка ответа WWW-Authenticate ДОЛЖНО быть включено в 401
(Неавторизованные) ответные сообщения. Значение поля состоит из at
по крайней мере один вызов, который указывает схему(ы) аутентификации и
параметры, применимые к Request-URI. Процесс аутентификации доступа HTTP описан в разделе "HTTP
Аутентификация: базовая и дайджест-аутентификация доступа» [43]. Пользователь
Агентам рекомендуется проявлять особую осторожность при разборе WWW-
Аутентифицируйте значение поля, так как оно может содержать более одного запроса,
или если предоставлено более одного поля заголовка WWW-Authenticate,
содержание самого вызова может содержать список разделенных запятыми
параметры аутентификации. Теги заголовков по-прежнему являются сильным сигналом для SEO. Джон Мюллер из Google сказал это сам: «[Когда] дело доходит до текста на странице, заголовок является действительно сильным сигналом, говорящим нам, что эта часть страницы посвящена этой теме». Теги заголовков — простая, но важная часть SEO. Используйте их с умом, и вы порадуете богов поисковых систем, а также своих пользователей. Вот семь лучших практик, которым стоит следовать при создании собственного. Теги заголовков — это HTML-теги, сообщающие браузеру, какой стиль следует использовать для отображения фрагмента текста на веб-странице. Если бы мы посмотрели HTML-код заголовка выше, он выглядел бы примерно так: HTML
<
html
>
<
body
>
<
h2
> Компьютерщики для компьютерщиков
h2
>
<
h4
>HTML Header Tag
h4
>
<
header
>
<
h2
>Это заголовок.
h2
>
0 0054
H5
> Это подзаголовок.
.0052
HTML
>
HTTP/1.1: определения полей заголовка
HTTP/1.1: определения полей заголовка часть протокола передачи гипертекста -- HTTP/1.1
RFC 2616 Филдинг и др. 14.1 Принять
Принять = "Принять" ":"
#( медиа-диапазон [ accept-params ] )
медиа-диапазон = ("*/*"
| ( тип "/" "*" )
| (тип "/" подтип)
) *( Параметр ";" )
принять параметры = ";" "q" "=" qvalue *(принять-расширение)
принять-расширение = ";" токен [ "=" ( токен | строка в кавычках ) ]
Примечание. Использование имени параметра "q" для разделения типа носителя
параметры из параметров расширения Accept связаны с историческими
упражняться. Хотя это предотвращает любой параметр типа носителя с именем
"q" от использования с диапазоном носителей, считается, что такое событие
маловероятно, учитывая отсутствие каких-либо параметров «q» в IANA
реестр типов носителей и редкое использование любого типа носителей
параметры в Принять. Не рекомендуется использовать будущие типы носителей.
регистрация любого параметра с именем "q".
Принять: аудио/*; q=0,2, аудио/базовый
Принять: текст/обычный; д=0,5, текст/html,
текст/x-dvi; q=0,8, текст/х-с
Принять: текст/*, текст/html, текст/html; уровень=1, */*
1) текст/html;уровень=1
2) текст/html
3) текст/*
4) */*
Принять: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
текст/html; уровень = 2; д = 0,4, */*; д = 0,5
текст/html; уровень=1 = 1
текст/html = 0,7
текст/обычный = 0,3
изображения/jpeg = 0,5
текст/html; уровень = 2 = 0,4
текст/html; уровень = 3 = 0,7
Примечание. Агенту пользователя может быть предоставлен набор параметров качества по умолчанию.
значения для определенных диапазонов носителей. Однако, если пользовательский агент не
закрытая система, которая не может взаимодействовать с другими агентами рендеринга,
этот набор по умолчанию должен быть настроен пользователем.
14.2 Принять кодировку
Принять кодировку = "Принять кодировку" ":"
1#(( кодировка | "*" )[ ";" "q" "=" qvalue ] )
Accept-Charset: iso-8859-5, unicode-1-1;q=0,8
14.3 Принять кодирование
Accept-Encoding = "Accept-Encoding" ":"
1#( кодировки [ ";" "q" "=" qvalue ] )
кодировки = ( кодирование контента | "*" )
Accept-Encoding: сжатие, gzip
Принять кодировку:
Принять кодировку: *
Accept-Encoding: сжатие; q = 0,5, gzip; q = 1,0
Accept-Encoding: gzip;q=1.0, идентификатор; д=0,5, *;д=0
1. Если кодировка контента является одной из кодировок контента, перечисленных в
поле Accept-Encoding, то оно приемлемо, если только оно не
сопровождается значением q, равным 0. (Как определено в разделе 3.9, а
qvalue 0 означает «неприемлемо».)
2. Специальный символ «*» в поле Accept-Encoding соответствует любому
доступное кодирование содержимого, явно не указанное в заголовке
поле.
3. Если допустимо несколько кодировок контента, то допустимый
предпочтительнее кодирование содержимого с наивысшим ненулевым значением q.
4. Кодирование содержимого «личность» всегда приемлемо, за исключением случаев, когда
специально отказано, потому что поле Accept-Encoding включает
"identity;q=0", или потому что поле включает "*;q=0" и не
явно не включать кодирование контента «личность». Если
Значение поля Accept-Encoding пусто, тогда только "идентификация"
кодировка приемлемая.
Примечание. Если запрос не включает поле Accept-Encoding,
и если "личное" кодирование контента недоступно, то
кодировки содержимого, обычно понятные клиентам HTTP/1.0 (т. е.
"gzip" и "compress") предпочтительнее; некоторые старые клиенты
некорректно отображать сообщения, отправленные с другими кодировками содержимого.
сервер также может принять это решение на основе информации о
конкретный пользовательский агент или клиент.
Примечание. Большинство приложений HTTP/1.0 не распознают значения qvalue или не подчиняются им.
связанные с кодированием контента. Это означает, что qvalues не будет
работают и не разрешены с x-gzip или x-compress.
14.4 Принять язык
Accept-Language = "Accept-Language" ":"
1#(язык-диапазон [ ";" "q" "=" qvalue ] )
язык-диапазон = (( 1*8ALPHA *("-" 1*8ALPHA)) | "*" )
Accept-Language: da, en-gb;q=0.8, en;q=0.7
Примечание. Такое использование правила сопоставления префиксов не означает, что
языковые теги назначаются языкам таким образом, чтобы
всегда верно, что если пользователь понимает язык с определенным
тег, то этот пользователь также будет понимать все языки с тегами
для которых этот тег является префиксом. Префиксное правило просто позволяет
использование тегов префикса, если это так.
Примечание. Если сделать выбор языковых предпочтений доступным для
пользователя, мы напоминаем разработчикам о том, что пользователи не
знакомы с деталями языкового сопоставления, как описано выше,
и должны давать соответствующие указания. Например, пользователи
можно предположить, что при выборе "en-gb" им будут обслуживаться любые
тип документа на английском языке, если британский английский недоступен. А
пользовательский агент может предложить в таком случае добавить «en», чтобы получить
наилучшее соответствие поведения.
14,5 Допустимые диапазоны
Поле заголовка ответа Accept-Ranges позволяет серверу
указать, что он принимает запросы диапазона для ресурса:
Accept-Ranges = "Accept-Ranges" ":" допустимые диапазоны
допустимые-диапазоны = 1#диапазон-единица | "никто"
Исходные серверы, которые принимают запросы диапазона байтов, МОГУТ отправлять
Допустимые диапазоны: байты
, но не обязаны этого делать. Клиенты МОГУТ генерировать диапазон байтов
запросы, не получив этот заголовок для ресурса
вовлеченный. Единицы диапазона определены в разделе 3.12.
Серверы, которые не принимают какой-либо запрос диапазона для
ресурс МОЖЕТ отправить
Допустимые диапазоны: нет
, чтобы посоветовать клиенту не пытаться запросить диапазон.
14.6 9 лет0471
Поле заголовка ответа Age содержит оценку отправителем
количество времени, прошедшее с момента ответа (или его повторной проверки)
генерируется на исходном сервере. Кэшированный ответ является «свежим», если
его возраст не превышает срока его свежести. Возрастные значения
рассчитывается, как указано в разделе 13.2.3.
Возраст = "Возраст" ":" значение возраста
значение возраста = дельта-секунды
Значения возраста представляют собой неотрицательные десятичные целые числа, представляющие время в
секунды.
931). Сервер HTTP/1.1 с кэшем ДОЛЖЕН
включать поле заголовка Age в каждый ответ, сгенерированный из его
собственный кеш. Кэши ДОЛЖНЫ использовать арифметический тип не менее 31
бит диапазона.
14.7 Разрешить
В поле заголовка сущности Allow указан набор поддерживаемых методов.
ресурсом, идентифицированным Request-URI. Цель этого
поле предназначено строго для информирования получателя о действительных методах
связанные с ресурсом. Поле заголовка Allow ДОЛЖНО быть
присутствует в ответе 405 (метод не разрешен).
Разрешить = "Разрешить" ":" #Метод
Пример использования:
Разрешить: ПОЛУЧИТЬ, ГОЛОВУ, ПОЛОЖИТЬ
Это поле не может помешать клиенту попробовать другие методы.
Тем не менее, показания, заданные значением поля заголовка Разрешить
СЛЕДУЕТ соблюдать. Фактический набор разрешенных методов определен
исходным сервером во время каждого запроса.
Поле заголовка Allow МОЖЕТ быть предоставлено с запросом PUT на
рекомендовать методы, которые должны поддерживаться новыми или измененными
ресурс. Сервер не обязан поддерживать эти методы и
СЛЕДУЕТ включать заголовок Allow в ответ, содержащий фактический
поддерживаемые методы.
Прокси-сервер НЕ ДОЛЖЕН изменять поле заголовка Allow, даже если он не
понимать все указанные методы, поскольку пользовательский агент может
иметь другие средства связи с исходным сервером.
14.8 Авторизация
Пользовательский агент, который хочет аутентифицировать себя на сервере--
обычно, но не обязательно, после получения ответа 401 —
поэтому, включив поле заголовка запроса авторизации с
запрос. Значение поля авторизации состоит из учетных данных
содержащий информацию об аутентификации пользовательского агента для
область запрашиваемого ресурса.
Авторизация = "Авторизация" ":" учетные данные
Аутентификация HTTP-доступа описана в разделе «Аутентификация HTTP:
Basic and Digest Access Authentication" [43]. Если запрос
аутентифицированы и указана область, одни и те же учетные данные ДОЛЖНЫ
быть действительным для всех других запросов в этой области (при условии, что
сама схема аутентификации иного не требует, такие
как учетные данные, которые варьируются в зависимости от значения вызова или использования
синхронизированные часы).
Когда общий кэш (см. раздел 13.7) получает запрос
содержащее поле авторизации, он НЕ ДОЛЖЕН возвращать
соответствующий ответ в качестве ответа на любой другой запрос, если только
из следующих конкретных исключений:
1. Если ответ включает элемент управления кешем "s-maxage"
директивы, кэш МОЖЕТ использовать этот ответ в ответ на
последующий запрос. Но (если указанный максимальный возраст имеет
пройден) прокси-кеш ДОЛЖЕН сначала перепроверить его с источником
сервер, используя заголовки запроса из нового запроса, чтобы разрешить
исходный сервер для аутентификации нового запроса. (Это
определенное поведение для s-maxage.) Если ответ включает «s-
maxage=0", прокси-сервер ДОЛЖЕН всегда перепроверять его перед повторным использованием.
Это.
2. Если ответ включает элемент управления кэшем «обязательная повторная проверка».
директивы, кэш МОЖЕТ использовать этот ответ в ответ на
последующий запрос. Но если ответ устарел, все кэши
ДОЛЖЕН сначала повторно проверить его на исходном сервере, используя
заголовки запроса из нового запроса, чтобы разрешить исходный сервер
для аутентификации нового запроса.
3. Если ответ включает директиву управления кешем "public",
он МОЖЕТ быть возвращен в ответ на любой последующий запрос.
14.9 Управление кэшем
Обратите внимание, что кэши HTTP/1.0 могут не реализовывать Cache-Control и
может реализовать только Pragma: no-cache (см. раздел 14.32).
Cache-Control = "Cache-Control" ":" 1#cache-directive
кеш-директива = кеш-директива-запрос
| кеш-ответ-директива
кеш-запрос-директива =
"без кеша"; Раздел 14.9.1
| "без магазина"; Раздел 14.9.2
| "max-age" "=" delta-seconds ; Раздел 14. 9.3, 14.9.4
| "max-stale" [ "=" delta-seconds ] ; Раздел 14.9.3
| "min-fresh" "=" дельта-секунд ; Раздел 14.9.3
| "без преобразования"; Раздел 14.9.5
| "только если кэшировано"; Раздел 14.9.4
| кеш-расширение ; Раздел 14.9.6
кеш-ответ-директива =
"общественный"; Раздел 14.9.1
| "private" [ "=" <"> 1#имя-поля <"> ] ; Раздел 14.9.1
| "без кеша" [ "=" <"> 1#имя-поля <"> ]; Раздел 14.9.1
| "без магазина"; Раздел 14.9.2
| "без преобразования"; Раздел 14.9.5
| «необходимо перепроверить»; Раздел 14.9.4
| "прокси-повторная проверка" ; Раздел 14.9.4
| "max-age" "=" delta-seconds ; Раздел 14.9.3
| "s-maxage" "=" дельта-секунд ; Раздел 14.9.3
| кеш-расширение ; Раздел 14.9.6
cache-extension = токен [ "=" ( токен | строка в кавычках ) ]
- Ограничения на кэширование; они могут быть наложены только
исходный сервер.
- Ограничения на то, что может хранить кэш; это может быть
налагается либо исходным сервером, либо пользовательским агентом.
- Модификации основного механизма выдоха; это может быть
налагается либо исходным сервером, либо пользовательским агентом.
- Элементы управления повторной проверкой и перезагрузкой кеша; это могут быть только
навязывается агентом пользователя.
- Контроль трансформации сущностей.
- Расширения системы кэширования.
14.9.1 Что можно кэшировать
14.9.2 Что может храниться в кэшах
14.9.3 Модификации основного механизма выдоха
14.9.4 Повторная проверка кэша и элементы управления перезагрузкой
14.9.5 Директива о запрете трансформации
14.9.6 Расширения управления кэшем
Cache-Control: private, community="UCI"
14.10 Соединение
Соединение = "Соединение" ":" 1#(токен соединения)
токен подключения = токен
Соединение: близко
14.11 Кодирование содержимого
Content-Encoding = "Content-Encoding" ":" 1#content-coding
Кодировка содержимого: gzip
14.
12 Язык содержимого Content-Language = "Content-Language" ":" 1#language-tag
Язык содержания: да
Язык содержимого: mi, en
14.13 Длина содержимого
Content-Length = "Content-Length" ":" 1*ЦИФРА
Длина содержимого: 3495
14.14 Расположение содержимого
Content-Location = "Content-Location" ":"
(абсолютныйURI | относительныйURI)
14.15 Содержимое-MD5
Content-MD5 = "Content-MD5" ":" md5-дайджест
md5-digest =
Примечание: хотя определение Content-MD5 точно такое же для
HTTP, как и в RFC 1864 для тел объектов MIME, существует несколько способов.
в котором применение Content-MD5 к телам объектов HTTP
отличается от его применения к телам сущностей MIME. Один из них
HTTP, в отличие от MIME, не использует Content-Transfer-Encoding и
использует Transfer-Encoding и Content-Encoding. Другое дело, что
HTTP чаще использует двоичные типы содержимого, чем MIME, поэтому
стоит отметить, что в таких случаях порядок байтов, используемый для вычисления
дайджест — это порядок передачи байтов, определенный для типа.
Наконец, HTTP позволяет передавать текстовые типы с любым из нескольких
соглашения о разрыве строки, а не только каноническая форма с использованием CRLF.
14.16 Диапазон содержимого
Content-Range = "Content-Range" ":" content-range-spec
спецификация диапазона содержимого = спецификация диапазона содержимого байта
byte-content-range-spec = байтовая единица SP
byte-range-resp-spec "/"
( длина экземпляра | "*" )
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
| "*"
длина экземпляра = 1*ЦИФРА
. Первые 500 байт:
байты 0-499/1234
. Вторые 500 байт:
байт 500-999/1234
. Все, кроме первых 500 байт:
байт 500-1233/1234
. Последние 500 байт:
байты 734-1233/1234
HTTP/1.1 206 Частичное содержимое
Дата: среда, 15 ноября 1995 г., 06:25:24 по Гринвичу.
Последнее изменение: среда, 15 ноября 1995 г., 04:58:08 по Гринвичу.
Диапазон содержимого: байты 21010-47021/47022
Длина содержимого: 26012
Тип контента: изображение/gif
Примечание: клиенты не могут зависеть от серверов при отправке 416 (запрошено
диапазон неудовлетворителен) ответ вместо ответа 200 (ОК) для
неудовлетворительный заголовок запроса Range, поскольку не все серверы
реализовать этот заголовок запроса.
14.17 Тип содержимого
Content-Type = "Content-Type" ":" media-type
Content-Type: text/html; кодировка = ISO-8859-4
14.18 Дата
Дата = "Дата" ":" HTTP-дата
Дата: вторник, 15 ноября 1994 г. , 08:12:31 по Гринвичу
1. Если код состояния ответа 100 (Продолжить) или 101 (Переключение
протоколы), ответ МОЖЕТ включать поле заголовка Date,
вариант сервера.
2. Если код состояния ответа указывает на ошибку сервера, т.е. 500
(внутренняя ошибка сервера) или 503 (служба недоступна), и это
неудобно или невозможно создать действительную дату.
3. Если на сервере нет часов, которые могут обеспечить
разумное приближение текущего времени, его реакции
НЕ ДОЛЖЕН включать поле заголовка Date. В этом случае правила
в разделе 14.18.1 ДОЛЖНЫ соблюдаться.
14.18.1 Работа исходного сервера без часов
14.19 ETag
ETag = "ETag" ":" сущность-тег
ETag: "xyzzy"
ETag: W/"xyzzy"
Этег: ""
14.20 Ожидать
Ожидать = "Ожидать" ":" 1#ожидание
ожидание = "100-продолжить" | ожидание-расширение
ожидание-расширение = токен [ "=" ( токен | строка в кавычках )
*параметры ожидания]
ожидаемые параметры = ";" токен [ "=" ( токен | строка в кавычках ) ]
14.21 Истекает
Expires = "Истекает" ":" HTTP-дата
Истекает: Чт, 01 декабря 1994 16:00:00 по Гринвичу
Примечание: если ответ содержит поле Cache-Control с максимальным
возрастная директива (см. раздел 14.9.3), эта директива имеет приоритет над
Истекает поле.
14.22 Из
От = "От" ":" почтовый ящик
От кого: [email protected]
14.23 Хост
Хост = "Хост" ":" хост [ ":" порт ] ; Раздел 3.2.2
ПОЛУЧИТЬ /pub/WWW/HTTP/1.1
Хост: www. w3.org
14.24 Если-совпадение
If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
Если-совпадение: "xyzzy"
Если-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
Если-совпадение: *
14.25 Если-Изменено-С
If-Modified-Since = "If-Modified-Since" ":" HTTP-дата
If-Modified-Since: сб, 29 октября 1994 г., 19:43:31 по Гринвичу
а) Если запрос обычно приводит к чему-либо, кроме
200 (ОК), или если переданная дата If-Modified-Since
недействителен, ответ точно такой же, как и при обычном GET.
Дата, более поздняя, чем текущее время сервера,
инвалид.
b) Если вариант был изменен с момента If-Modified-Since
date ответ точно такой же, как и при обычном GET.
c) Если вариант не был изменен с момента действительного If-
Modified-Since date, сервер ДОЛЖЕН возвращать 304 (не
Измененный) ответ.
Примечание. Поле заголовка запроса Range изменяет значение If-
Модифицировано-с; подробности см. в разделе 14.35.
Примечание. Время If-Modified-Since интерпретируется сервером, чей
часы могут быть не синхронизированы с клиентом.
Примечание. При обработке поля заголовка If-Modified-Since некоторые
серверы будут использовать функцию сравнения точной даты, а не
функция «меньше чем» для принятия решения о том, следует ли отправлять 304 (не
Измененный) ответ. Чтобы получить наилучшие результаты при отправке If-
Поле заголовка Modified-Since для проверки кэша, клиенты
рекомендуется использовать точную строку даты, полученную в предыдущем Last-
По возможности изменено поле заголовка.
Примечание. Если клиент использует произвольную дату в поле If-Modified-Since
заголовок вместо даты, взятой из заголовка Last-Modified для
тот же запрос, клиент должен осознавать тот факт, что это
date интерпретируется в понимании времени сервером.
клиент должен учитывать несинхронизированные часы и проблемы с округлением
из-за разных кодировок времени между клиентом и
сервер. Это включает в себя возможность условий гонки, если
документ изменился между моментом его первого запроса и
дата If-Modified-Since последующего запроса и
возможность проблем, связанных с рассогласованием часов, если If-Modified-
Поскольку дата выводится из часов клиента без коррекции
к часам сервера. Поправки для разных временных баз
между клиентом и сервером в лучшем случае приблизительны из-за сетевых
задержка.
14.26 Если не совпадает
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
Если-нет-совпадения: *
14,27 Если-диапазон
If-Range = "If-Range" ":" (entity-tag | HTTP-date)
14.28 Если-без изменений-с
If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-дата
If-Unmodified-Since: сб, 29 октября 1994 г., 19:43:31 по Гринвичу
14.29 Последнее изменение
Last-Modified = "Last-Modified" ":" HTTP-дата
Последнее изменение: Вт, 15 ноября 1994 г., 12:45:26 GMT
14.30 Адрес
Местоположение = "Местоположение" ":" absoluteURI
Местонахождение: http://www.w3.org/pub/WWW/People.html
Примечание. Поле заголовка Content-Location (раздел 14.14) отличается
from Location в том, что Content-Location идентифицирует оригинал
местонахождение объекта, включенного в запрос. Поэтому
возможно, чтобы ответ содержал поля заголовка как для местоположения,
и Контент-Местоположение. Также см. раздел 13.10 для кеша.
Требования некоторых методов.
14.31 Макс-Форвардс
Макс. вперед = "Макс. вперед" ":" 1*ЦИФРА
14.32 Прагма
Pragma = "Pragma" ":" 1#pragma-directive
прагма-директива = "без кеша" | расширение-прагма
extension-pragma = токен [ "=" ( токен | строка в кавычках ) ]
Примечание: поскольку значение «Прагма: без кеша в качестве ответа
поле заголовка на самом деле не указано, оно не обеспечивает
надежная замена "Cache-Control: no-cache" в ответе
14.
33 Прокси-аутентификация Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge
14.34 Прокси-авторизация
Прокси-Авторизация = "Прокси-Авторизация" ":" учетные данные
14,35 Диапазон
14.
35.1 Диапазоны байтов спецификатор диапазонов = спецификатор диапазонов байтов
спецификатор диапазонов байтов = единица байтов "=" набор диапазонов байтов
байт-диапазон-набор = 1#( байт-диапазон-спецификация | суффикс-байт-диапазон-спецификация)
byte-range-spec = первая позиция байта "-" [последняя позиция байта]
первый байт-поз = 1*ЦИФРА
последний байт-поз = 1*ЦИФРА
suffix-byte-range-spec = "-" длина суффикса
длина суффикса = 1*ЦИФРА
- Первые 500 байт (байтовые смещения 0-499 включительно): байты=0-
499
- Вторые 500 байт (байтовые смещения 500-999 включительно):
байты=500-999
- Последние 500 байт (байтовые смещения 9500-9999 включительно):
байт=-500
- или байт=9500-
- Только первый и последний байты (байты 0 и 9999): байты=0-0,-1
- Несколько легальных, но не канонических спецификаций второго 500
байты (байтовые смещения 500-999 включительно):
байты=500-600,601-999
байты=500-700,601-999
14.
35.2 Запросы на получение диапазона Диапазон = "Диапазон" ":" спецификатор диапазонов
— наличие заголовка Range в безусловном GET изменяет
что возвращается, если GET в противном случае успешен. В других
словами, ответ содержит код состояния 206 (частичный
содержание) вместо 200 (ОК).
- Наличие заголовка Range в условном GET (запрос
используя один или оба из If-Modified-Since и If-None-Match, или
один или оба из If-Unmodified-Since и If-Match) изменяют то, что
возвращается, если GET в остальном успешен и
условие верно. Это не влияет на 304 (не изменено)
ответ возвращается, если условие ложно.
14.36 Реферер
Referer = "Referer" ":" ( absoluteURI | относительныйURI )
Реферер: http://www.w3.org/hypertext/DataSources/Overview.html
14.37 Повторить-после
Retry-After = "Retry-After" ":" (HTTP-дата | дельта-секунды)
Повторить после: пятница, 31 декабря 1999 г., 23:59:59 GMT
Повторить после: 120
14.38 Сервер
Сервер = "Сервер" ":" 1*( продукт | комментарий )
Сервер: CERN/3.0 libwww/2.17
Примечание. Раскрытие конкретной версии программного обеспечения сервера может
сделать серверную машину более уязвимой для атак
против программного обеспечения, которое, как известно, содержит дыры в безопасности. Сервер
разработчикам рекомендуется сделать это поле настраиваемым
вариант.
14,39 ТЭ
TE = "TE" ":" #(t-коды)
t-кодировки = "прицепы" | (передача-расширение [принять-параметры])
TE: сдуть
ТЭ:
TE: прицепы, сдутые; q=0,5
1. Всегда допустимо «фрагментированное» кодирование передачи. Если
указано ключевое слово "трейлеры", клиент указывает, что это
готов принять поля трейлера в ответе на фрагменты на
от имени себя и любых нижестоящих клиентов. Подразумевается
что, если дано, клиент заявляет, что либо все
нижестоящие клиенты готовы принимать поля трейлера в
перенаправленный ответ, или что он попытается буферизовать
ответ от имени нижестоящих получателей.
Примечание: HTTP/1.1 не определяет никаких средств для ограничения размера
фрагментированный ответ, чтобы клиент мог быть уверен в буферизации
весь ответ.
2. Если тестируемое кодирование передачи является одним из
кодировки, перечисленные в поле TE, то она приемлема, если только она не
сопровождается значением q, равным 0. (Как определено в разделе 3.9,
qvalue 0 означает «неприемлемо».)
3. Если допускается множественное кодирование передачи, то
допустимое кодирование передачи с наибольшим ненулевым значением q равно
предпочтительно. «Разбитое» кодирование передачи всегда имеет qvalue
из 1.
14.40 Трейлер
Trailer = "Trailer" ":" 1#имя поля
. Передача-кодирование
. Длина содержимого
. Трейлер
14.41 Кодирование передачи
Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
Transfer-Encoding: фрагментировано
14.42 Обновление
Обновление = "Обновление" ":" 1#продукт
Обновление: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
14.43 Агент пользователя
User-Agent = "User-Agent" ":" 1*( продукт | комментарий )
Агент пользователя: CERN-LineMode/2.15 libwww/2.17b3
14,44 Варьируется
Vary = "Vary" ":" ("*" | 1#имя поля)
14.45 Через
Via = "Via" ":" 1#(полученный-протокол полученный [комментарий])
полученный-протокол = [имя-протокола "/"] версия-протокола
имя-протокола = токен
версия протокола = токен
получено = (хост [ ":" порт ] ) | псевдоним
псевдоним = жетон
Через: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Через: 1.0 Рикки, 1.1 Этель, 1.1 Фред, 1.0 Люси
можно свернуть в
Через: 1.0 Рикки, 1.1 Мерц, 1.0 Люси
14.46 Предупреждение
Предупреждение = "Предупреждение" ":" 1#значение-предупреждения
warning-value = предупреждающий код SP предупреждающий агент SP предупредительный текст
[дата предупреждения SP]
код предупреждения = 3 ЦИФРЫ
предупреждающий агент = (хост [ ":" порт ] ) | псевдоним
; имя или псевдоним сервера добавления
; заголовок Warning для использования при отладке
предупреждающий текст = строка в кавычках
дата-предупреждения = <"> HTTP-дата <">
- Предупреждения, которые появляются в начале ответа, имеют приоритет над
те, которые появляются позже в ответе.
- Предупреждения в предпочитаемом пользователем наборе символов имеют приоритет
над предупреждениями в других наборах символов, но с идентичными предупреждениями.
коды и предупреждающие агенты.
14.47 WWW-аутентификация
WWW-аутентификация = "WWW-аутентификация" ":" 1#вызов
Как использовать теги заголовков: лучшие практики SEO
Что такое тег заголовка?
Что такое тег заголовка?
Как и заголовки в печатном тексте, теги заголовков используются для заголовка или введите контент под ними. Теги заголовков HTML следуют иерархии от
до
.
- Теги h2 используются для обозначения наиболее важного текста, например, основной темы или заголовка контента.
- Теги h3 и h4 обычно используются в качестве подзаголовков.
- Наконец, теги h5, H5 и H6 могут использоваться для обеспечения дополнительной структуры внутри этих подразделов.
Теги заголовков полезны для пользователей и поисковых систем. Для ваших пользователей они дают им предварительный просмотр контента, который они собираются прочитать.
Для поисковых систем, таких как Google, они предоставляют контекст о том, о чем ваша страница, и обеспечивают иерархию. Думайте о тегах заголовков как о названиях глав в книге. Дайте им быстрое сканирование, и у вас будет довольно хорошее представление о том, что охватывает контент.
Теги заголовков важны для SEO, потому что они помогают Google понять ваш контент, а также потому, что они делают вашу страницу более удобной для пользователей, делая ваш контент более читабельным и доступным.
Теперь давайте перейдем к рекомендациям.
1. Используйте теги заголовков для создания структуры
Теги заголовков обеспечивают структуру и контекст для вашей статьи. Каждый заголовок должен давать читателю представление об информации, которую он может почерпнуть из текста абзаца, следующего ниже.
Полезный способ подумать о тегах заголовков — сравнить их с оглавлением научно-популярной книги:
- Ваш h2 знакомит с темой, которой посвящена ваша страница, точно так же, как заголовок сообщает читателю, о чем книга. это все о.
- h3 похожи на главы книги, описывающие основные темы, которые вы затронете в разделах статьи.
- Последующие заголовки, от h4 до H6, служат дополнительными подзаголовками в каждом разделе, так же как глава книги может быть разбита на несколько подтем.
При разработке статьи для блога или целевой страницы подумайте об основных идеях, которые вы хотите донести до своих посетителей.
Это ваши теги заголовков. Используйте их, чтобы помочь вам написать план.
2. Разбивайте блоки текста на подзаголовки
Сканируемая статья — это читабельная статья, а читабельная статья — это та статья, которая с большей вероятностью будет хорошо работать в поисковых системах.
Это потому, что Google любит вознаграждать контент, который удобен для пользователя. Контент, который легко читать, по определению более удобен для пользователя, чем контент, который не читается.
Когда статью можно отсканировать, пользователи могут остаться, чтобы прочитать ее, вместо того, чтобы вернуться в Google. Кроме того, они также с большей вероятностью поделятся ею со своими друзьями.
Хотя социальные сигналы не являются прямым фактором ранжирования, чем больше репостят статью, тем выше вероятность естественного получения обратных ссылок, которые являются фактором ранжирования.
3. Включите ключевые слова в теги заголовков
Как сказал нам Мюллер, Google использует теги заголовков для сбора контекста для вашей страницы.
Как и во всем, на что Google обращает внимание, это означает, что стоит включать ключевые слова в теги заголовков.
Это не означает, что вы должны любой ценой втиснуть ключевые слова. Будьте благоразумны, не спамьте.
Вы, наверное, заметили, что многие теги заголовков в этой статье содержат ключевые слова.
Фактически, h3 для этого раздела буквально включает «ключевые слова!» Но на самом деле я имею в виду ключевое слово «теги заголовков».
Это одно из целевых ключевых слов для этой статьи, поэтому я включил его во многие h3. Однако я не включил его в каждый отдельный h3, потому что такое повторение может оттолкнуть читателей.
Ваша страница в первую очередь должна быть читабельной. Если ключевые слова подходят естественным образом, вы также можете добавить их.
Всегда в первую очередь думайте о своем пользователе. Затем оптимизируйте для Google.
4. Оптимизация для избранных сниппетов
К сожалению, многие маркетологи не задумываются о тегах заголовков (надеемся, что эта статья изменит это!).
Но они могут существенно повлиять на ваши шансы получить желанный избранный фрагмент.
Вот как.
Избранные фрагменты абзаца
Взглянули на избранный фрагмент абзаца?
Оптимизируйте тег заголовка, чтобы он соответствовал ключевому слову голосового поиска. Затем ответьте на запрос непосредственно ниже, поместив текст в теги абзаца
.
Например, журнал Search Engine Journal выиграл этот избранный сниппет за «Как удалить поисковую систему по умолчанию в Chrome?», отчасти благодаря оптимизированному для ключевых слов h3:
Скриншот из поиска [как удалить поисковую систему по умолчанию в Chrome хром], Google, октябрь 2021 г.
Скриншот из SearchEngineJournal, октябрь 2021 г.
List Featured Snippets
Вы также можете использовать теги заголовков для выделения различных элементов в списке.
Google может использовать ваши подзаголовки для создания собственного маркированного или нумерованного списка для избранного фрагмента.
Вот пример.
Найдите [как быстро облегчить мигрень], и Google создаст список ответов, используя h3 из этой статьи WebMD.
Скриншот из поиска [как быстро облегчить мигрень], Google, октябрь 2021 г.
Скриншот с сайта WebMD, октябрь 2021 г.
5. Используйте только один h2
Давайте развеем распространенный SEO-миф.
Google заявил, что нет проблем с использованием нескольких h2.
Однако это не означает, что лучше всего использовать несколько h2 на странице.
Почему бы и нет?
h2 большие, и для читателей они выглядят как заголовки. Используйте несколько h2 на своей странице, и она начнет выглядеть немного неуправляемой.
Хотите убедиться, что на вашем сайте не осталось нескольких h2?
Запустите свой домен с помощью поискового инструмента, такого как Screaming Frog.
Переключитесь на вкладку h2, чтобы сразу увидеть, есть ли у вас страницы, на которых полностью отсутствует h2 или на которых есть несколько h2.
Затем щелкните раскрывающееся меню «Фильтр», чтобы экспортировать те, которые вы хотите исправить.
Скриншот Screaming Frog, октябрь 2021 г.
Такой же отчет доступен для h3s. Ура!
6. Соблюдайте согласованность тегов заголовков
В маркетинге и дизайне ваша цель — обеспечить единообразие взаимодействия с пользователями.
Когда сайт достигает этого вплоть до мельчайших деталей, это впечатляет.
Стремитесь произвести впечатление последовательными тегами заголовков на вашем сайте.
Если вы решите использовать формат заглавных букв, придерживайтесь его на всех страницах (и наоборот, если вы выбираете регистр предложений).
Кроме того, используйте более короткие заголовки.
Тег заголовка не место для написания абзаца текста с ключевыми словами для Google.
Вместо этого используйте его как мини-заголовок для следующего раздела текста.
Хорошее эмпирическое правило: заголовки должны иметь ту же длину, что и теги заголовков (не более 70 символов).
Чем больше вы можете установить ожиданий для посетителей вашего сайта и постоянно оправдывать их, тем счастливее (и более заинтересованными) они будут.
7. Сделайте теги заголовков интересными
Это правило относится ко всему вашему копирайтингу, а не только к заголовкам.
В вашем первоначальном черновике могут быть скучные заголовки, которые вы используете для создания плана.
Это нормально, но вы всегда должны просматривать и исправлять свои заголовки перед публикацией, чтобы сделать их привлекательными для ваших посетителей.
Да, теги заголовков позволяют сканировать статью. Но в идеале они не сканируют полностью.
Интригующие теги заголовков побуждают посетителей задуматься и немного почитать.
Особое внимание уделите тегу h2. Пользователи замечают h2s.
В значительной степени ваш h2 может определять, будут ли посетители вообще прокручивать страницу вниз.
Сделайте все возможное, чтобы написать один удивительный тег h2, который соответствует поисковому запросу пользователя и вызывает у него интерес к чтению вашей статьи.
Оставайтесь на шаг впереди с тегами заголовков
Хорошо создавайте заголовки, и вы не только сделаете свой контент более сканируемым, но и заинтригуете посетителей, чтобы они продолжали читать.
Кроме того, оптимизированные теги заголовков могут помочь вам выиграть избранные фрагменты и облегчить поисковым системам понимание вашей страницы.
Станьте звездой SEO. Используйте стратегические теги заголовков. Ваш сайт этого заслуживает!
Избранное изображение: Пауло Бобита/SearchEngineJournal
Категория SEO
Подробное руководство Различие этих тегов
В языке программирования HTML есть два важных тега, а именно
иПравильное применение этих тегов даже повышает поисковую оптимизацию (SEO)! В этой статье мы расскажем больше об этих тегах и их различиях.
Содержание
- Заголовок HTML
- Заголовок HTML
- Различия между заголовком и заголовком в HTML Устаревшие браузеры
- 1. Добавление правила с помощью каскадных таблиц стилей (CSS)
- 2. HTML5Shiv
- Советы и рекомендации по использованию тега
- — наиболее часто используемый тег в элементе HTML это <название>. Например,
- — Используйте тег для вставки метаданных на веб-сайт.
- – Действительные элементы тега
- – Тег может использоваться для размещения значков на веб-странице. Например,
- — используйте тег для оптимизации веб-страниц для социальных сетей.
- Заключение
HTML Head листы и ссылки
к сценариям или их определениям. Это особенно важно для устаревших браузеров.Хотя желательно, чтобы включал элемент заголовка HTML , это не всегда необходимо. Современным браузерам это не нужно, потому что они могут успешно отображать веб-сайт без тега
. Однако традиционные браузеры всегда требуют его . Следовательно, веб-разработчик может отформатировать свой HTML-код следующим образом:
<голова> голова> |
или
|
Заголовок HTML
Тег
Будучи относительно новой записью, тег заголовка в HTML требует наличия начального тега <> и конечного тега >. Веб-разработчики должны учитывать, что возможно для вставки нескольких тегов
Вот пример, который поможет вам понять текстовый эффект тега
Код HTML5:
<тело>
<заголовок> Это заголовок.Это подзаголовок.Это метаданные. заголовок>
тело> |
Результат:
Можно также использовать тег
Код HTML5:
<тело> Гики для гиков
<заголовок> <ссылка = «https://www.geeksforgeeks.org/fundamentals-of-algorithms/»> Алго | <ссылка = «https://www.geeksforgeeks.org/data-structures/»> ДС | <ссылка = «https://www.geeksforgeeks.org/category/program-output/»> языка | <ссылка = «https://www.geeksforgeeks.org/company-interview-corner/»> Интервью | <ссылка = «https://www. geeksforgeeks.org/студенческий уголок/»> студента | <ссылка = «https://www.geeksforgeeks.org/gate-cs-notes-gq/»> Ворота | <ссылка = «https://www.geeksforgeeks.org/articles-on-computer-science-subjects-gq/»> темы CS | <ссылка = «https://www.geeksforgeeks.org/quiz-corner-gq/»> Викторины заголовок>
|
Результат:
Веб-разработчики могут успешно реализовать тег
Различия между заголовком и заголовком в HTML
Теги
и— Тег заголовка:
HTML-тег
предоставляет браузеру общую информацию или метаданные о веб-странице. Эти метаданные включают заголовок, а также ссылки и определения таблиц стилей или скриптов.– Тег заголовка:
Тег HTML
Использование тега
Веб-разработчики могут задаться вопросом , будут ли новые теги HTML5 , такие как тег
Однако этот эффект не гарантируется. Устаревший браузер может отображать ошибку, если он сталкивается с тегом
1. Добавление правила с помощью каскадных таблиц стилей (CSS)
В процессе разработки сайта к коду можно добавить правило CSS. Это заставит новые теги HTML5, такие как
заголовок, раздел, нижний колонтитул, отступ, навигация, главная, статья, рисунок { дисплей: блок; } |
Внедрение этого правила CSS приведет к тому, что указанные теги будут вести себя как блоки и, следовательно, не будут прерывать выполнение веб-сайта. Однако это решение не работает в IE8 и предыдущих версиях этого устаревшего браузера. В IE8 невозможно стилизовать какой-либо тег, не входящий в официальный список тегов, с помощью CSS, поэтому невозможно заблокировать тег
2. HTML5Shiv
HTML5Shiv (https://github. com/afarkas/html5shiv) — это инструмент , который веб-разработчики могут использовать, чтобы устаревший браузер Internet Explorer 8 распознавал новые элементы HTML5, такие как тег
Инструмент вызывает функцию document.createElement("section") . При этом он заставляет Internet Explorer 8 to немедленно распознавать элемент раздела . Таким образом, код стиля CSS может быть вставлен в этот элемент, что приведет к распознаванию и блокировке новых тегов HTML5.
Советы и рекомендации по использованию тега
Тег
необходим в веб-разработке. В дополнение к предоставлению информации о веб-страницах, также может быть использован для оптимизации . Есть много трюков, которые помогают с этой целью. Вот несколько советов, которые помогут вам правильно использовать тег на вашем веб-сайте.— Наиболее часто используемый тег в элементе HTML
— <заголовок> |
Этот тег
— Используйте тег
для вставки метаданных на веб-сайт.Во время администрирования блога важно добавлять дополнительную информацию, которая поможет читателям узнать больше о каждом сообщении. Некоторые примеры такой информации включают автора, тему сообщения, описание, дату и ключевые слова. Одной из основных функций тега
является предоставление метаданных о веб-странице. Поэтому для достижения этой цели разработчики могут использовать следующий формат кода:<мета-кодировка=”UTF-8″> <метаимя=”ключевые слова” содержание=”HTML, PHP, JavaScript”> |
– Допустимые элементы тега
Допустимые элементы тега
включают meta, ссылку, заголовок, стиль, скрипт, noscript и базовый . С помощью этих элементов веб-разработчик может определить, как веб-страница будет распознаваться, а затем отображаться интернет-технологиями, такими как браузеры, боты и поисковые системы. Вот различные функции этих элементов:- — Предоставляет метаданные и устанавливает кодировку веб-страницы UTF-8, например. <метакодировка="utf-8">
-
Домашняя страница -
— устанавливает основной URL-адрес для всех других относительных URL-адресов на веб-сайте, например. - <ссылка> — Может использоваться для создания ссылки между веб-страницей и внешними ресурсами , такие как таблицы стилей CSS, например. ссылка rel="таблица стилей" href="styles.css">
- — используется для создания CSS на странице,например.<стиль>/$… $/стиль>
- — используется для вставки Javascript,например.
- — включается при указании на отсутствие альтернативы Javascript.
— Тег
может использоваться для размещения значков на веб-странице. Например,– Используйте тег
для оптимизации веб-страниц для социальных сетейВеб-разработчики могут использовать тег
для оптимизации своих веб-страниц для продвижения в социальных сетях путем улучшения метаданных с помощью тегов Open Graph. Они форматируют внешний вид вашей веб-страницы на сайтах социальных сетей,таких как Facebook. Например,com/page.html"> <мета-свойство=”og:type” content=”веб-сайт”> <мета-свойство=”og:site_name” content=”Имя сайта”> <мета-свойство=”og:locale” content=”en_US”> <мета-свойство=”статья:автор” содержание=””> |
Форматирование веб-страниц описанным выше способом оптимизирует ваш веб-сайт для социальных сетей. Это повышает узнаваемость бренда в Интернете и повышает общий рейтинг вашего веб-сайта на страницах результатов поисковых систем (SERPS) 9.0028 .
Заключение
Мы узнали разницу между тегами
и- Тег HTML предоставляет браузеру метаданные о веб-странице,такие как ее заголовок,ссылки и определения таблиц стилей или скриптов..
- HTML-тег
содержит вводную информацию,а также может быть контейнером для динамического содержимого,например логотипа,средств навигации или формы поиска.
Приведенные выше рекомендации указывают на разницу между тегами заголовка и заголовка . Поняв эту разницу,веб-разработчики могут создавать привлекательные,функциональные и оптимизированные веб-сайты.
- Автор
- Последние сообщения
Должность решает все
Должность решает все:ваш ресурс для изучения и создания:CSS,JavaScript,HTML,PHP,C++и MYSQL.
Последние сообщения от Position is Everything (посмотреть все)
- HTML:язык гипертекстовой разметки
Элемент HTML
представляет вводное содержимое,обычно группу вводных или навигационных средств. Он может содержать некоторые элементы заголовка,а также логотип,форму поиска,имя автора и другие элементы.
Исходный код этого интерактивного примера хранится в репозитории GitHub.Если вы хотите внести свой вклад в проект интерактивных примеров,клонируйте https://github.com/mdn/interactive-examples и отправьте нам запрос на включение.
Категории контента | Вытекающее содержимое,пальпируемое содержимое. |
---|---|
Разрешенный контент | Текущее содержимое,но без или потомка. |
Отсутствие тега | Нет,начальный и конечный теги обязательны. |
Разрешенные родители | Любой элемент,который принимает потоковое содержимое. Обратите внимание,что
|
Неявная роль ARIA | баннер или нет соответствующей роли,если он является потомком статьи ,стороны ,основной ,nav или раздел элемент,или элемента с роль=статья ,4 основной, |
Разрешенные роли ARIA | группа ,презентация или нет |
Интерфейс DOM | HTMLЭлемент |
Замечания по использованию
Элемент
не разделяет содержимое и,следовательно,не вводит новый раздел в структуру.Тем не менее,элемент
обычно содержит заголовок окружающего раздела ().0053 h2 — h6
элемент),но это ,а не .
Историческое использование
Хотя элемент
не попадал в спецификации до HTML5,на самом деле он существовал в самом начале HTML. Как видно на самом первом веб-сайте,он изначально использовался как элемент . В какой-то момент было решено использовать другое название. Это позволило
свободно выполнять другую роль позже.
Атрибуты
Этот элемент включает только глобальные атрибуты.
Примеры
Заголовок страницы
<заголовок>Заголовок главной страницы
заголовок>
<статья><заголовок>Планета Земля
Опубликовано Джейн Смит в среду,
заголовок>Мы живем на сине-зеленой планете,на которой так много еще невидимого.
статья>
Технические характеристики
Спецификация | Статус | Комментарий |
---|---|---|
HTML Living Standard Определение ' | Уровень жизни | |
HTML5 Определение ' | Рекомендация |
Совместимость с браузером
Таблица совместимости на этой странице создана из структурированных данных. Если вы хотите внести свой вклад в данные,посетите https://github.com/mdn/browser-compat-data и отправьте нам запрос на включение.
Desktop | Mobile | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Chrome | Edge | Firefox | Internet Explorer | Opera | Safari | Android webview | Chrome для Android | Firefox для Android | Opera для Android | Safari для iOS | Samsung Internet | |
header | 17 Chrome Полная поддержка 5 Край Полная поддержка 12 | Firefox Полная поддержка 4 | ИЭ Полная поддержка 9 | Опера Полная поддержка 11.1 | Сафари Полная поддержка 5 | Веб-просмотр Android Полная поддержка Да | Chrome Android Полная поддержка Да | Firefox Android Полная поддержка 4 | Opera Android Полная поддержка 11.1 | Сафари iOS Полная поддержка 4.2 | Самсунг Интернет Android Полная поддержка Да |
Легенда
- Полная поддержка
- Полная поддержка
См. также
- Другие элементы,относящиеся к разделу:
,
,
,
,
,
,05
0 9 0 4 0,90 90
,
,
,
,
,
,
.
- Использование разделов и структур HTML
HTTP-заголовки и классические балансировщики нагрузки
HTTP-запросы и HTTP-ответы используют поля заголовка для отправки информации о HTTP Сообщения. Поля заголовка представляют собой пары "имя-значение",разделенные двоеточием. возврат каретки (CR) и перевод строки (LF). Стандартный набор полей заголовка HTTP:определено в RFC 2616,Заголовки сообщений. Существуют также нестандартные заголовки HTTP. доступны (и автоматически добавляются),которые широко используются приложениями. Некоторые из нестандартные заголовки HTTP имеют Префикс X-Forwarded
. Поддержка классических балансировщиков нагрузки следующие заголовки X-Forwarded
.
Дополнительные сведения о соединениях HTTP см. в разделе Запрос маршрутизации в Руководстве пользователя Elastic Load Balancing .
Предпосылки
Убедитесь,что настройки вашего прослушивателя поддерживают заголовки X-Forwarded.Для большего информацию см. в разделе Конфигурации прослушивателя для Классические балансировщики нагрузки.
Настройте веб-сервер для регистрации IP-адресов клиентов.
X-Forwarded Headers
- X-Forwarded-For
- X-Forwarded-Proto
- X-Forwarded-Port
X-Forwarded-For
The The The заголовок добавляется автоматически и помогает вы определяете IP-адрес клиента,когда используете балансировщик нагрузки HTTP или HTTPS. Поскольку балансировщики нагрузки перехватывают трафик между клиентами и серверами,ваш сервер журналы доступа содержат только IP-адрес балансировщика нагрузки. Чтобы увидеть IP-адрес клиента,используйте Заголовок запроса Ниже приведен пример Ниже приведен пример заголовка запроса Заголовок запроса X-Forded-For 447
X-Forded-For
X-Forded-For
Заголовок запроса X-Forwarded-For
.Elastic Load Balancing сохраняет IP-адрес клиента в заголовке запроса X-Forwarded-For
и передает заголовок на ваш сервер. Если заголовок запроса X-Forwarded-For
не включен в запрос,балансировщик нагрузки создает его с IP-адресом клиента адрес в качестве значения запроса. В противном случае балансировщик нагрузки добавляет IP-адрес клиента. адрес к существующему заголовку и передает заголовок на ваш сервер. Заголовок запроса X-Forwarded-For
может содержать несколько IP-адресов которые разделены запятыми. Крайний левый адрес — это IP-адрес клиента,на который отправлен запрос. был сделан впервые. За этим следуют любые последующие идентификаторы прокси в цепь. X-Forwarded-For
имеет следующую форму:X-Forwarded-For:
client-ip-address
X-Forwarded-For
заголовок запроса для клиент с IP-адресом 203.0.113.7
. X-Forwarded-For:203.0.113.7
X-Forwarded-For
для клиент с IPv6-адресом 2001:DB8::21f:5bff:febf:ce22:8a2e
. X-Forwarded-For:2001:DB8::21f:5bff:febf:ce22:8a2e
X-Forwarded-Proto
X-Forwarded-Proto
помогает определить протокол (HTTP или HTTPS),который клиент использовал для подключения к балансировщику нагрузки. Ваш сервер журналы доступа содержат только протокол,используемый между сервером и балансировщиком нагрузки;они не содержат информации о протоколе,используемом между клиентом и нагрузкой балансир. Чтобы определить протокол,используемый между клиентом и балансировщиком нагрузки,использовать Заголовок запроса X-Forwarded-Proto
. Elastic Load Balancing сохраняет протокол используется между клиентом и балансировщиком нагрузки в X-Forwarded-Proto
заголовок запроса и передает заголовок на ваш сервер.