Избавляемся от ошибки «http» при загрузке изображений в WordPress. Краткое описание протокола HTTP

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

HTTPS и редиректы

Рассмотрим пример. Допустим, что у нас есть сайт dnsimple.com . Его канонический URL-адрес — https://dnsimple.com . Тем не менее, существует четыре различных способа, с помощью которых можно подключиться к сайту, и нужно обеспечить, чтобы при любом из них пользователь перенаправлялся на https://dnsimple.com :

Исходный способ	Тип
http://dnsimple.com	HTTP + no-www
https://dnsimple.com	HTTPS + no-www
http://www.dnsimple.com	HTTP + www
https://www.dnsimple.com	HTTPS + www

Настройка htaccess редиректов HTTP на HTTPS часто является причиной путаницы. Не всегда понятно, как правильно обрабатывать через HTTPS редиректы с WWW на не-WWW (или наоборот ), и почему для этого нужен сертификат SSL / TLS . Чтобы правильно настроить эти перенаправления, необходимо понять основные принципы обработки запросов HTTPS .

Далее мы рассмотрим, в каком порядке устанавливается соединение по протоколу HTTPS , как происходит обработка HTTP-запросов и настройка редиректов с поддержкой HTTPS .

Поток запроса HTTPS

На приведенном выше изображении показана схема прохождения запросов / ответов HTTPS . Для простоты мы разбили все действия на три фазы:

На первом этапе клиент и сервер договариваются о деталях шифрования, таких как протокол шифрования и набор шифров. Также происходит обмен информацией, необходимой для переключения на защищенное соединение: открытые ключи, сведения о сертификате и т.д. Эта фаза называется «SSL / TLS рукопожатие »;
На втором этапе клиент готовит HTTP-запрос , шифрует его и отправляет на сервер для обработки. Сервер принимает зашифрованный HTTP-запрос , расшифровывает его, обрабатывает и выдает HTTP response (ответ );
На третьем этапе, сервер шифрует ответ и отправляет его клиенту для обработки. Клиент получает зашифрованный HTTP response , дешифрует и обрабатывает его (например, браузер начинает загружать и отображать элементы ).

Эта схема потока редиректа с HTTP на HTTPS применима к любому запросу, независимо от содержимого ответа HTTP .

Выше я написал запрос HTTP и ответ HTTP для определенных целей (обратите внимание, что я использовал HTTP , а не HTTPS ). С точки зрения содержимого и структуры важно понимать, что HTTPS-запрос — это HTTP-запрос , но передаваемый через защищенное соединение (TLS / SSL ).

HTTPS-согласования и редиректы

Одна из самых распространенных ошибок при настройке HTTPS-редиректов — это предположение, что вам не нужен сертификат SSL при переадресации клиента с одного домена на другой.

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

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

Не забывайте, что редирект — это HTTP-ответ с кодом 301 (иногда 302 или 307 ):

HTTP/1.1 301 Moved Permanently Server: nginx Date: Mon, 01 Aug 2016 14:41:25 GMT Location: https://dnsimple.com/

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

Если бы все происходило иначе, то редирект бы обрабатывался перед проверкой сертификата SSL . Тогда клиент и сервер были бы вынуждены общаться с помощью обычного HTTP-соединения , которое не шифруется.

Если нужно перенаправить клиента с любой страницы домена https://www.example.com на другую, необходим установленный на сервере валидный сертификат SSL , который распространяется на весь домен www.example.com .

Например, чтобы перенаправить клиента с https://www.example.com на https://example.com , необходимо иметь сертификат, который распространяется на оба или два отдельных сертификата (для каждого хоста соответственно ).

Стратегии HTTPS-редиректов

Мы рассмотрели, как обрабатывается редирект с HTTP на HTTPS через htaccess после SSL / TLS согласования. А также выяснили, что для перенаправления клиентов с сайта или страницы на HTTPS нужен валидный сертификат SSL , который охватывает оба домена. Далее я расскажу об общих стратегиях настройки HTTPS-редиректов .

Существует два типа настройки редиректов с HTTPS :

Редирект на уровне сервера;
Редирект на уровне приложений.

Термин сервер обозначает любой сервер, который находится перед веб-приложением и обрабатывает входящий HTTP-запрос . Например, front-end сервер, сервер балансировки нагрузки или единичного приложения.

Термин приложение обозначает веб-приложение, которое может быть либо столь же простым, как PHP-скрипт , либо более сложным, таким как серверное Unicorn-приложение интерпретации Ruby on Rails .

Выполнение HTTPS-редиректов на уровне сервера

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

Такой подход является более быстрым, так как сервер может обрабатывать редирект без взаимодействия с приложением. В то же время конфигурация серверов менее гибкая по сравнению с тем, что можно сделать с помощью полноценного языка программирования.
htaccess редирект HTTP на HTTPS на уровне сервера используется для массового перенаправления. Например, редиректа с WWW на не-WWW версию домена с HTTPS (или наоборот ).

Следующий фрагмент кода является примером конфигурации Nginx , в котором задается редирект с http://example.com , http://www.example.com и https://www.example.com на https://example.com :

server { listen 80; server_name example.com www.example.com; return 301 https://example.com$request_uri; } server { listen 443 ssl; server_name example.com www.example.com; # ssl configuration ssl on; ssl_certificate /path/to/certificate.crt; ssl_certificate_key /path/to/private.key; if ($http_host = www.example.com) { return 301 https://example.com$request_uri; } }

Реализация редиректа на уровне сервера более предпочтительна, но она не всегда осуществима, поскольку вы можете не иметь доступа к конфигурации сервера. Это касается виртуального хостинга или таких платформ, как Heroku , Azure или Google Platform .

Выполнение HTTPS-редиректа на уровне приложений

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

Такой подход немного медленнее, потому что сервер должен принять запрос, обработать код приложения (или взаимодействовать с сервером приложений ) и вернуть ответ.

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

Пакет Goland и net/http

Можно использовать http.Redirect .

Ruby on Rails

Можно настроить редирект на уровне маршрутизатора, использовать промежуточное программное обеспечение Rack или метод redirect_to внутри контроллера:

constraints(host: /www.example.com/) do get "*", to: redirect("https://example.com") end

PHP

Используйте функцию header , чтобы отправить HTTP-заголовок перенаправления:

В некоторых случаях это единственно возможный подход. Например, если нужно перенаправить клиентов с WWW на не-WWW версию домена, с HTTPS на Heroku или Azure (или наоборот ), то придется указать оба домена в одном приложении, установить сертификат и через условия обрабатывать редирект на уровне приложений.

Альтернативные способы выполнения HTTPS-редиректа

Существует несколько альтернативных способов редиректа с HTTP на HTTPS .

В некоторых ситуациях отсутствует доступ к конфигурации сервера, а платформа, на которой размещен сайт, не позволяет использовать язык программирования. В качестве типичного примера можно привести Amazon S3 для размещения статических сайтов. В этом случае нужно выяснить, предоставляет ли платформа параметры HTTPS-редиректов , которые можно настроить.

Другой вариант заключается в использовании автономного, независимого приложения для редиректов. Например, если нужно перенаправить клиентов с https://alpha.com на https://beta.com . Тогда для домена alpha.com в качестве DNS можно указать другой сервис или сервер, на котором размещен beta.com . А также настроить редирект на уровне сервера или установить приложение, которое будет выступать в качестве редиректора. При этом также необходим валидный сертификат для alpha.com , который будет установлен там, где необходимо осуществить редирект.

Часто ли у посетителей Вашего сайта (интернет-магазина, или другим видом обработки персональных данных) возникают сомнения: можно ли доверять данному ресурсу?

В далеком 1994 году ребята из Netscape Communications позаботились об особо подозрительных пользователях всемирной сети и придумали волшебную штуку — HTTPS.

Что такое HTTPS?

HTTPS (HyperText Transfer Protocol Secure) - расширение протокола HTTP, для поддержки шифрования в целях защиты и повышения уровня безопасности персональных данных пользователей. В отличие от HTTP с TCP-портом 80, для HTTPS по умолчанию используется TCP-порт 443.

Да-да, довольно сложно и не очень понятно. .

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

Например, пользователь Сбербанк.Онлайн отправил данные в текстовом формате (текст “123”) через сайт с https. К этим данным на сервере отправителя (???) прикрепляется ключ, шифрующий введенные данные. Таким образом, отправленные данные невозможно перехватить с помощью сторонних программ.

Данные в протоколе HTTPS передаются поверх криптографических протоколов SSL или TLS. Именно эти протоколы поддерживают зашифрованное соединение между сервером и браузером пользователя .

Что думают поисковики об https?

Гугл однозначно за шифрование трафика. И в обновленной 56 версии Google Chrome сайты уже помечены как надежный (на https) и ненадежный (на http):

При этом справедливо отметить, что переход на безопасный протокол — далеко не первостепенный фактор ранжирования. Однако нет сомнений, что в дальнейшем вес https будет только расти.

Что касается Яндекса — официальной информации по этому поводу нет, но при этом все сервисы компании уже перешли на защищенный протокол.

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

3 этапа перехода сайта с http на https

Шаг 1: cертификат безопасности SSL

Приобрести и настроить сертификат безопасности (SSL), выданный удостоверяющим центром

SSL (Secure Socket Layer) — сертификат, это индивидуальная цифровая подпись вашего домена. Вы можете выбрать любой из 5 видов сертификата безопасности :

Самоподписанный

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

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

имеет короткий срок службы;
некоторые браузеры могут не поддерживать и страница не будет открываться;
не распространяется на поддомены;
не поддерживает URL на кирилице.

Domain Validation (Валидация по домену)

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

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

выдается на один домен (при смене придется покупать еще раз)
действует от года до 3 лет
минимум личных данных на сайте
не поддерживает URL на кирилице

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

высокий уровень защиты
срок выдачи от 3 до 10 раб дней
стоимость дороже

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

среди SSL-сертификатов самый высокий класс защиты
прибавляется вес и авторитетность ресурса
высокая стоимость

Wildcsrd (поддомен)

Надстройка для сертификатов, защита всех прямых поддоменов указываемых

Шаг 2: настройка данных в системах аналитики

Яндекс.Вебмастер. Необходимо на старом домене с указанием новой директивы host и указать главное зеркало. У ведомить поисковую систему о новом протоколе.
Яндекс.Вебмастер — Индексирование — Переезд сайта.
Только после того как в Яндекс.Вебмастер появится соответствующие изменения настраиваем 301 редирект (важно только после того как появится уведомление, что сайт доступен на https настраиваем 301 редирект)
В Google Analytics меняем представителя с http // на https

Шаг 3: обновляем внутренние ссылки

Старые ссылки, увы, не будут работать, меняем ссылки в контенте, в стилях CSS, в скриптах, шаблонах на https . Были http//site.ru станут https//site.ru. Существует большое количество утилит, плагинов для автоматической замены старых ссылок.

На WP, например, можно воспользоваться плагином Velvet Blues Update URLs

Обновляем изображения (при необходимости). Рекомендуем прописывать и ссылки и путь к изображениям без указания домена, а в формате /uplods/photo/sertifikat https)

Карту сайта , файл . Проверяем, чтобы был указан исключительно протокол https.

Подведем итог:

Чтобы улучшить доверие пользователей и поисковых систем к вашему сайту с помощью переезда домена на https, нужно технически реализовать 3 вещи:

Получить и настроить сертификат безопасности (SSL), подходящий вашему сайту.
Дать понять поисковым системам что ваш сайт изменил адрес (переехал с http на https).
Произвести внутреннюю оптимизацию сайта с учетом нового доменного имени.

Столкнулись с трудностями при переезде с http на https? Или хотите их избежать? Закажите у нас seo-аудит и мы поможем Вам со сменой домена.

Подпишись и следи за выходом новых статей в нашем

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

и зачем оно нужно

Перед переводом сайта на HTTPS соединение следует разобраться, что это такое и как оно работает. HTTPS является защищенным вариантом HTTP протокола (Hypertext в нем передаются необходимые данные для работы страниц (название браузера, разрешение экрана, наличие Cookie и т. п.).

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

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

HTTPS надо обязательно использовать на банковских сайтах или в онлайн магазинах. Если на этих ресурсах отсутствует то браузер запретит соединение, и высветится предупреждение об опасности. Как следствие, сайт потеряет доверие своих пользователей.

Что такое SSL/TLS сертификат

Главным нововведением в HTTPS является обязательное применение цифрового SSL сертификата. Это файл, в котором хранится вся информация (IP адрес сервера, страна сайта, E-mail владельца и т. п.). Цифровой документ находится в зашифрованном виде на сервере сайта и на сервере центра сертификации (GoDaddy, Comodo и т. п.). При каждом соединении эти файлы сравниваются, и если они одинаковы, то соединение продолжается. Иначе появляется предупреждение безопасности.

Многим читателям неизвестно, как сделать защищенное соединение https. Первым действием потребуется получить SSL сертификат у проверенного центра. Существуют разные типы данных документов:

DV - подтверждают только домен (для небольших сайтов и блогов).
OV - проверяется домен и организация.
EV - расширенная проверка (появится зеленая полоса и замочек в браузере).

Наиболее предпочтительным для магазинов и банков считается EV вариант. Дальше идут дополнительные уточнения в виде:

SGC (поддерживает старые браузеры).
Wildcard (поддержка субдоменов).
SAN (альтернативные домены в одном сертификате).
IDN (поддержка национальных доменов www).

Для большинства сайтов достаточно использовать DV SSL сертификат. Он стоит недорого и гарантирует защиту от фишинга.

Как перевести сайт на защищенное соединение

Все чаще владельцев онлайн бизнеса интересует, как создать защищенное соединение https. Для этих действий придется внести некоторые изменения в программный код страниц. Наиболее важным является написать дополнительное правило в.htaccess файл. В нем хранится код, предназначенный для настройки Apache веб-сервера.

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

Получение SSL сертификата.
Установка сертификата на сервер.
Изменение внутренних ссылок сайта.
Настройка redirect на 301 порт.
Изменение Hosts в robots.txt.

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

Получение сертификата и его установка на сервер

Теоретически разобрались, как сделать https соединение, перейдем к действиям. Первым этапом необходимо получить SSL сертификат у одного из проверенных центров. В интернете можно найти множество различных вариантов в разном ценовом диапазоне. В нынешнее время для получения бесплатного документа существует 2 центра:

WoSign.
Startssl.

Остальные сервисы требуют оплаты. Сумма зависит от типа сертификата и его дополнительных особенностей (мультидоменность, поддержка старых браузеров и т. п.). Центры сертификации:

Reg.ru.
Godaddy.
Hostland.
Symantec.
Comodo.
GlobalSign.
Thawte.

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

генерация CSR запроса;
заполнение почты сайта (admin@[адрес сайта]);
заполнение информации о владельце домена (для EV и OV документа).

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

Теперь перейдите на сайт хостинга и найдите раздел «SSL сертификат» или же обратитесь в поддержку. Потребуется предоставить информацию о CSR коде, приватном ключе и сертификате. Не забудьте включить поддержку SSL в панели хостинга.

Как создать https соединение на постоянной основе

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

То есть вместо http://site.ru/img/bg.png установить: //site.ru/img/bg.png.

Нужно убрать HTTP из названий ссылок. Если сомневаетесь, то позовите WEB-программиста или фрилансера, он быстро это настроит. Выискивать ссылки можно через редактор кода в каждом файле или же найти всю информацию через поиск в PhpMyAdmin.

После настройки ссылок нужно указать поисковикам об изменении. Откройте файл robots.txt и в строчке Host: вместо HTTP поставьте HTTPS.

Вместо http://example.ru вставьте: https://example.ru.

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

Для автоматического перенаправления на безопасное соединение вставьте этот скрипт в.htacess файл, некоторым помогает:

RewriteEngine on

RewriteCond %{HTTP:X-Forwarded-Proto} !https

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}

Но в большинстве случаев этот метод не работает. В этих ситуациях обратитесь к администратору хостинга, он сумеет внести правильные настройки. Редирект начнет работать после перезапуска сервера, как правило, в течение 24 часов.

Кроме того потребуется изменить настройки в панели вебмастера "Яндекс" или Google. Потребуется в разделе настроек индексирования перейти в пункт главного зеркала и установить HTTPS. Кроме того, потребуется перенести:

sitemap.xml;
исключения URL;
геолокацию;
ссылки Disawov Tool для Гугла.

После этого остается подождать окончания переиндексации. В этот период активность на сайте уменьшится, но потом все стабилизируется.

соединение в WordPress

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

easy HTTPS Redirection;
HTTPS (SSL).

Первый заменяет ссылки, а второй позволяет указать SSL сертификат. Кроме того, перейдите в раздел параметры->общие. Здесь нужно изменить URL и указать HTTPS протокол. Позаботьтесь, чтобы старые страницы тоже имели защищенное соединение. После изменения ссылок проведите настройку редиректа и измените файл robots.txt.

Больше не должно возникать вопросов, как сделать https соединение на сайте. На большинстве хостингов для включения защитного режима нужно лишь написать в техподдержку. Они назначат специалиста, и он сам выполнит настройку.

HTTP (HyperText Transfer Protocol - протокол передачи гипертекста) был разработан как основа World Wide Web.

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

Структура HTTP-запроса

HTTP-запрос состоит из заголовка запроса и тела запроса, разделенных пустой строкой. Тело запроса может отсутствовать.

Заголовок запроса состоит из главной (первой) строки запроса и последующих строк, уточняющих запрос в главной строке. Последующие строки также могут отсутствовать.

Запрос в главной строке состоит из трех частей, разделенных пробелами:

Метод (иначе говоря, команда HTTP):

GET - запрос документа. Наиболее часто употребляемый метод; в HTTP/0.9, говорят, он был единственным.

HEAD - запрос заголовка документа. Отличается от GET тем, что выдается только заголовок запроса с информацией о документе. Сам документ не выдается.

POST - этот метод применяется для передачи данных CGI-скриптам. Сами данные следуют в последующих строках запроса в виде параметров.

PUT - разместить документ на сервере. Насколько я знаю, используется редко. Запрос с этим методом имеет тело, в котором передается сам документ.

Ресурс - это путь к определенному файлу на сервере, который клиент хочет получить (или разместить - для метода PUT). Если ресурс - просто какой-либо файл для считывания, сервер должен по этому запросу выдать его в теле ответа. Если же это путь к какому-либо CGI-скрипту, то сервер запускает скрипт и возвращает результат его выполнения. Кстати, благодаря такой унификации ресурсов для клиента практически безразлично, что он представляет собой на сервере.

Версия протокола -версия протокола HTTP, с которой работает клиентская программа.

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

Здесь запрашивается корневой файл из корневой директории web-сервера.

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

Параметр: значениe .

Таким образом задаются параметры запроса. Это является необязательным, все строки после главной строки запроса могут отсутствовать; в этом случае сервер принимает их значение по умолчанию или по результатам предыдущего запроса (при работе в режиме Keep-Alive).

Перечислю некоторые наиболее употребительные параметры HTTP-запроса:

Connection (соединение)- может принимать значения Keep-Alive и close. Keep-Alive ("оставить в живых") означает, что после выдачи данного документа соединение с сервером не разрывается, и можно выдавать еще запросы. Большинство браузеров работают именно в режиме Keep-Alive, так как он позволяет за одно соединение с сервером "скачать" html-страницу и рисунки к ней. Будучи однажды установленным, режим Keep-Alive сохраняется до первой ошибки или до явного указания в очередном запросе Connection: close.
close ("закрыть") - соединение закрывается после ответа на данный запрос.

User-Agent - значением является "кодовое обозначение" браузера, например:

Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)

Accept - список поддерживаемых браузером типов содержимого в порядке их предпочтения данным браузером, например для моего IE5:

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

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

Значение этого параметра используется в основном CGI-скриптами для формирования ответа, адаптированного для данного браузера.

Referer - URL, с которого перешли на этот ресурс.

Host - имя хоста, с которого запрашивается ресурс. Полезно, если на сервере имеется несколько виртуальных серверов под одним IP-адресом. В этом случае имя виртуального сервера определяется по этому полю.

Accept-Language - поддерживаемый язык. Имеет значение для сервера, который может выдавать один и тот же документ в разных языковых версиях.

Формат HTTP-ответа

Формат ответа очень похож на формат запроса: он также имеет заголовок и тело, разделенное пустой строкой.

Заголовок также состоит из основной строки и строк параметров, но формат основной строки отличается от таковой в заголовке запроса.

Основная строка запроса состоит из 3-х полей, разделенных пробелами:

Версия протокола - аналогичен соответствующему параметру запроса.

Код ошибки - кодовое обозначение "успешности" выполнения запроса. Код 200 означает "все нормально" (OK).

Словесное описание ошибки - "расшифровка" предыдущего кода. Например для 200 это OK, для 500 - Internal Server Error.

Наиболее употребительные параметры http-ответа:

Connection - аналогичен соответствующему параметру запроса.
Если сервер не поддерживает Keep-Alive (есть и такие), то значение Connection в ответе всегда close.

Поэтому, на мой взгляд, правильной тактикой браузера является следующая:
1. выдать в запросе Connection: Keep-Alive;
2. о состоянии соединения судить по полю Connection в ответе.

Content-Type ("тип содержимого") - содержит обозначение типа содержимого ответа.

В зависимости от значения Content-Type браузер воспринимает ответ как HTML-страницу, картинку gif или jpeg, как файл, который надо сохранить на диске, или как что-либо еще и предпринимает соответствующие действия. Значение Content-Type для браузера аналогично значению расширения файла для Windows.

Некоторые типы содержимого:

text/html - текст в формате HTML (веб-страница);
text/plain - простой текст (аналогичен "блокнотовскому");
image/jpeg - картинка в формате JPEG;
image/gif - то же, в формате GIF;
application/octet-stream - поток "октетов" (т.е. просто байт) для записи на диск.

На самом деле типов содержимого гораздо больше.

Content-Length ("длина содержимого") - длина содержимого ответа в байтах.

Last-Modified ("Модифицирован в последний раз") - дата последнего изменения документа.

Иногда возникают ситуации, когда при запросе сайта веб-браузером выдается ошибка. Такие ошибки имеют цифровой код и определенное описание.

(101-199) Информационные ответы

Такие ответы указывают на то, что запрос того или иного клиента принят и происходит его непосредственная обработка.

100 - Continue - принята первая часть запрос, клиент может продолжить его передачу.
101 - Switching Protocols - сервисом выполняются определенные требования клиента, а также переключаются протоколы, что соответствует данным в поле заголовка Upgrade.

(200-299) Успешные запросы клиента

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

200 - OK - успешная обработка запроса клиента, а в ответе сервера имеются все запрашиваемые данные.
201 - Created - такой код состояния может быть использован при смене URL. Помимо кода, сервером также выдается заголовок Location, в котором содержится вся информация о месте перемещения всех новых данных.
202 - Accepted - запрос принимается, но его обработка происходит не сразу. Тело содержимого ответа также может содержать определенную информацию о данной транзакции. Не предоставляются никакие гарантии того, что запрос будет удовлетворен, даже если во время приемы он был допустимым.
203 - Non-Authoritative Information - в заголовке содержимого имеется информация, которая была получена из локальной копии или от третьей стороны.
204 - No Content - в ответе имеется только заголовок и код состояния, само тело ответа не дается. При получении такого ответа документ браузера не должен обновляться. Код может возвращаться обратно после того, как пользователь по пустым участкам изображения.
205 - Reset Content - происходит очистка формы, которая используется для дополнительных вводных данных, браузером.
206 - Partial Content - сервером возвращается только некоторая часть данных. Используется в ответе на запрос при указании заголовка Range. В заголовке Content-Range сервером должен указываться определенный диапазон, который входит в ответ.

(300-399) Переадресация

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

300 - Multiple Choices (несколько вариантов на выбор) - затребованный URL может включать несколько ресурсов. В возвращенном сервером теле содержимого должны находиться определенные данные о правильном выборе ресурса.
301 - Moved Permanently (ресурс перемещен на постоянной основе) - требуемый URL сервер уже не использует, поэтому и не выполняется операция, которая указана в запросе. В заголовке Location предоставляются данные о новом местонахождении запрашиваемого документа. При последующих запросах необходимо уже указывать новый URL.
302 - Moved Temporarily (ресурс временно перемещен) - временное перемещение затребованного URL. В заголовке Location указывается новое месторасположение. После получения кода состояния клиент должен разрешить запрос при помощи нового URL, но в дальнейшем пользоваться только старым.
303 - See Other (смотрите другой ресурс) - поиск затребованного URL осуществляется посредством указания другого URL, который находится в заголовке Location.
304 - Not Modified (не изменился) - является кодом ответа на заголовок lf-Modified-Since, если не произошло изменение URL. Тело содержимого не присутствует, поэтому клиентом должна использоваться его локальная копия.
305 - Use Proxy (используйте прокси-сервер) - обращаться к запрашиваемому ресурсу необходимо посредством прокси-сервера, который указывается в поле Location. Также в этом поле имеется URL необходимого прокси-сервера. Запрос необходимо повторить получателю.

(400-499) Неполные запросы клиента

В данном диапазоне коды ответов означают, что запрос клиента неполный. Также это может означать, что клиенту необходимо ввести дополнительную информацию.

400 - Bad Request (некорректный запрос) - сервер не понимает запрос из-за синтаксиса malformed. Запрос можно повторить, но только после проведения определенных модификаций.
401 - Unauthorized (нет разрешения) - пользователь должен подтвердить свою подлинность. В ответе должно присутствовать поле заголовка WWW-Authenticate с вызовом, который применяется к запрошенному ресурсу. Запрос может повториться, но уже с подходящим полем заголовка Authorization. Если в данном поле уже имеются рекомендации по установлению подлинности, то код состояния 401 показывает, что такие рекомендации не подходят для установления подлинности.
402 - Payment Required (требуется оплата) - код зарезервирован и будет использоваться в будущем, но он еще не реализован в HTTP.
403 - Forbidden (доступ запрещен) - отклонение запроса, так у сервера нет возможности ответить клиенту.
404 - Not Found (ресурс не найден) - по указанному URL уже не существует необходимого документа, то есть сервер не нашел ничего, что могло бы соответствовать данному запросу.
405 - Method Not Allowed (недопустимый метод) - в заголовке Allow отмечается, что применяемый клиентом метод не поддерживается.
406 - Not Acceptable (неприемлемый запрос) - идентифицируемый ресурс может генерировать только объекты с характеристикой содержимого, которые не согласуются с заголовками приема.
407 - Proxy Authentication Required (необходима регистрация на сервере-представителе) - указывает на необходимость установления подлинности клиента прокси-серверу. Прокси-сервером возвращается поле заголовка Proxy-Authenticate, где содержится определенный вызов. Запрос может быть повторен, но уже при указании подходящего поля заголовка.
408 - Request Timeout (время обработки запроса истекло) - запрос не осуществился клиентом за время ожидания сервером. Запрос можно повторить позже.
409 - Conflict (конфликт) - запрос не выполняется, так как существует конфликт с состоянием ресурса. Предполагается, что пользователь устранит конфликт и передаст запрос повторно.
410 - Gone (ресурса больше нет) - затребованный URL больше не т на сервере.
411 - Length Required (необходимо указать длину) - запрос не принимается сервером, так как не определен Content-Length. Запрос можно повторить, указав в поле заголовка Content-Length длину тела сообщения.
412 - Precondition Failed (не выполнено предварительное условие) - запрос не обрабатывается сервером, так как объект запроса намного больше, чем он может обработать. При таком раскладе возможно закрытие соединения. Если такое состояние временно, то сервер указывает время в заголовке Retry-After, через которое клиент может повторить попытку.
413 - Request Entity Too Large (запрашиваемый элемент слишком велик) - запрос не обрабатывается сервером из-за его огромной величины.
414 - Request-URI Too Long (идентификатор ресурса в запросе слишком длинный) - запрос не обрабатывается сервером, так как его URL довольно длинный.
415 - Unsupported Media Type (неподдерживаемый тип устройства) - отказ сервера в обслуживании запроса, так как запрошенным ресурсом не поддерживается формат объекта запроса.

(500-599) Ошибки сервера

В данном диапазоне указывается, что запрос, скорее всего, не будет выполнен, так как сервер столкнулся с определенной ошибкой.

500 - Internal Server Error (внутренняя ошибка сервера) - во время обработки запроса один из компонентов сервера столкнулся с определенной ошибкой конфигурации.
501 - Not Implemented (функция не реализована) - запрос клиента не может быть выполнен, так как для выполнения запроса необходима поддержка некоторых функциональных возможностей. Может выдаваться в случае, когда сервер не может распознать метод запроса.
502 - Bad Gateway (дефект шлюза) - сервер при работе в качестве прокси-сервера получил недопустимый ответ в цепочке запросов от следующего сервера.
503 - Service Unavailable (служба недоступна) - служба временно недоступна, но через некоторое время доступ может возобновиться. При наличии у сервера определенных данных, он может выдать ответ с заголовком Retry-After.
504 - Gateway Timeout (время прохождения через шлюз истекло) - шлюзом или сервером превышен лимит времени.
505 - HTTP Version Not Supported (неподдерживаемая версия HTTP) - сервером не поддерживается версия протокола HTTP, которая использовалась в запросе.