{{ HTTPSidebar }}
Протокол передачи гипер текста ( Hypertext Transfer Protocol - HTTP) это прикладной протокол для передачи данных. Он используется для общения между веб браузерами и веб серверами, хотя в принципе HTTP может использоваться и для других целей. Протокол следует классической клиент-серверной модели, когда клиент открывает соединение, инициирует запрос, а затем ждет ответа. HTTP не поддерживает статусы взаимодействия клиента и сервера ( stateless protocol )
Не смотря на то, что HTTP основан на TCP/IP , он так же может использовать любой транспорт.
Документация
- HTTP заголовки / HTTP headers
- Заголовки HTTP сообщения используются для точного описания загружаемого ресурса или поведения сервера или клиента. Пользовательские заголовки можно добавить используя 'X-' префикс; другие перечислены в IANA registry, содержание которого в свою очередь определено в RFC 4229. IANA так же поддерживает регистр предложенных новых HTTP заголовков .
- HTTP куки / HTTP cookies
- Как работают куки можно почитать в RFC 6265. В момент получения HTTP запроса , сервер может послать Set-Cookie заголовок в ответе. После этого, значение куки посылается с каждым запросом к этому серверу. Делается это в форме Cookie HTTP header. В дополнение, можно указать истечение срока куки, а так же ограничения для специфического домена или пути.
- Базовая аутентификация / Basic access authentication
- В контексте HTTP транзакции, базовая аутентификация это метод, используемый HTTP юзер агентом (User Agent) для предоставления имени и пароля пользователя при инициации запроса.
- HTTP pipelining FAQ
- HTTP/1.1 Pipelining FAQ
- Контроль доступа (совместное использование ресурсов между разными источниками) / HTTP access control (CORS)
- Кросс-сайт HTTP запросы это запросы к ресурсам, находящимся домене отличающимся от того, с которого производится запрос. Напрмер, ресурс загружаемый с домена А (
https://domaina.example) - HTML веб страница, запрашивает ресурс с домена Б (https://domainb.foo) - изображение, используяimgтег (https://domainb.foo/image.jpg). Это происходит сплошь и рядом в мире веба - страницы загружают различные ресурсы в кросс-сайт манере, включая стили (CSS) , изображения и скрипты и другие ресурсы. - Контроль предварительной загрузки DNS / Controlling DNS prefetching
- Firefox 3.5 выполняет предварительную загрузку DNS / DNS prefetching. При помощи данной функции Firefox заранее получает доменное имя ссылки, по которой следует пользователь, а также резолвит URL'ы для объектов ссылки на которые указаны в документе, включая изображения, CSS, JavaScript и так далее. Эта предварительная загрузка выполняется в фоновом режиме, так что вполне вероятно, что к моменту обращения к объектам в документе, DNS уже получен. Это уменьшает задержки, когда , например пользователь кликает на ссылку.
- Коды ответа / HTTP response codes
- Коды ответа HTTP указывают на результат выполнения определенного HTTP запроса. Ответы сгруппированы в пять категорий: информационные ответы, удачные ответы, перенаправления, ошибки клиента, и ошибки сервера.
Краткая история HTTP
С момента своего первого появления в качестве протокола с одним единственным методом (GET) , возвращаемого только HTML страницы, HTTP прошел через несколько ревизий. Первая версия, документированная как HTTP/0.9 in 1991 считается первоначальной. Очень простой, у него был рудимент в виде поискового функционала через HTML {{ HTMLElement("isindex") }} элемент и расширение URL при помощи символа '?'.
Затем в 1992 была опубликована версия, которая с минимальными изменениями стала HTTP/1.0 (финализирована в RFC 1945 в Мае 1996). Одно важное улучшение по сравнению с предыдущей версией заключалось в возможности передавать файлы разных типов, а не только HTML : Изображения, видео, скрипты, CSS документы. Это было достигнуто использованием MIME типов вместе с заголовком Content-Type.
В 1995, IETF начала разработку новой версии HTTP, которая должна была стать HTTP/1.1. Она очень быстро стала широко использоваться, и была официально стандартизирована в 1997 в RFC 2068, с небольшими исправлениями в RFC 2616 2 года спустя.
HTTP/1.1 превнесла возможность повторно использовать установленное подключение для последовательных запросов, что значительно улучшило производительность протокола, уменьшив уровень задержек между запросами. Это особенно полезно в случаях сложных HTML документов, которым необходимо получить несколько последовательных файлов, таких как изображения или стили. Также в новой версии появился Host: заголовок, который позволяет одному серверу на один порт, получать запросы для нескольких веб сайтов; эта возможность проложила путь к размещению нескольких веб сайтов на одном сервере, что значительно уменьшило затраты на хостинг.
С тех пор HTTP протокол развивался добавлением новых заголовков, определяющих новые поведения без необходимости фундаментального изменения протокола. Неизвестные заголовки просто игнорируются серверами и клиентами.
В настоящее время HTTP/1.1 пересматривается рабочей группой IETF HTTPbis Working Group.
HTTP сессия
Так как HTTP это клиент-серверный протокол , HTTP сессия состоит из трёх фаз:
- Клиент устанавливает TCP соеденения (или другое соединение, если не используется TCP транспорт).
- Клиент отправляет запрос и ждёт ответа.
- Сервер обрабатывает запрос и посылает ответ, в котором содержится код статуса и соответствующие данные.
Начиная с версии HTTP/1.1, после третьей фазы соединение не закрывается, так как клиенту позволяется инициировать другой запрос. То есть, вторая и третья фазы могут повторяться.
Установка соединения
Так как HTTP это клиент-серверный протокол, соединение всегда устанавливается клиентом. Открыть соединение в HTTP это значит установить соединение через соответствующий транспорт, обычно TCP.
В случае с TCP, в качестве порта HTTP сервера по умолчанию на компьютере используется порт 80, хотя другие также часто используются, например 8000 or 8080. URL загружаемой страницы содержит доменное имя и порт, который можно и не указывать если он соответствует порту по умолчанию.
Отправка запроса клиента
Когда соединение установлено user-agent может послать запрос. (user-agent это обычно веб браузер, но может им не быть) Клиентский запрос это текстовые директивы, разделенные между собой при помощи CRLF (переноса строки). Сам запрос включает в себя три блока:
- Первые строки содержат метод запроса и его параметры:
- путь к документу - абсолютная URL без указания протокола и доменного имени
- версию HTTP протокола
- Каждая последующая строка представляет собой HTTP заголовок и передает серверу некоторую информацию о типах предпочитаемых данных (наприм. какой язык , какие MIME типы) или инструкции меняющие поведение сервера (наприм. не отправлять ответ, если он уже в кэше) . Эти HTTP заголовки формируют блок, который заканчивается пустой строкой.
- Последний блок является не обязательным и содержит дополнительные данные. По большей части используется методом POST.
Примеры запросов
- Получаем главную страницу developer.mozilla.org, https://developer.mozilla.org/, и говорим серверу, что user-agent предпочитает страницу на французском, если это возможно:
GET / HTTP/1.1 Host: developer.mozilla.org Accept-Language: fr
Обращаем внимание на пустую строку в конце, которая отделяет блок данных от блока заголовков. Так как в запросе отсутствует
Content-Length:HTTP заголовок, блок с данными пуст и сервер может начать обработку запроса, как только получит пустую строку, означающую конец заголовков. - Отправляем результат сабмита формы:
POST /contact_form.php HTTP/1.1 Host: developer.mozilla.org Content-Length: 64 Content-Type: application/x-www-form-urlencoded name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue
Структура ответа от сервера
После того как присоединенный агент отправил свой запрос, веб сервер обрабатывает его и отправляет ответ. По аналогии с клиентским запросом, ответ сервера это текстовые директивы разделенные между собой CRLF, сгруппированные в три разных блока:
- Первая строка - строка статуса, состоит из подтверждения используемой HTTP версии и статуса запроса (и его значения в виде понятным человеку).
- Последующие строки представляют собой HTTP заголовки, дающие клиенту некоторую информацию о посылаемой дате (прим. тип, размер, алгоритм сжатия, подсказки по кэшированию). Так же как и в случае клиентского запроса, эти HTTP заголовки формируют блок, заканчивающийся пустой строкой.
- Последний блок содержит данные (если таковые имеются).
Примеры ответов
- Успешное получение веб страницы:
HTTP/1.1 200 OK Date: Sat, 09 Oct 2010 14:28:02 GMT Server: Apache Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT ETag: "51142bc1-7449-479b075b2891b" Accept-Ranges: bytes Content-Length: 29769 Content-Type: text/html <!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
- Сообщение о том, что запрашиваемый ресурс был перемещен:
HTTP/1.1 301 Moved Permanently Server: Apache/2.2.3 (Red Hat) Content-Type: text/html; charset=iso-8859-1 Date: Sat, 09 Oct 2010 14:30:24 GMT Location: https://developer.mozilla.org/ (this is the new link to the resource; it is expected that the user-agent will fetch it) Keep-Alive: timeout=15, max=98 Accept-Ranges: bytes Via: Moz-Cache-zlb05 Connection: Keep-Alive X-Cache-Info: caching X-Cache-Info: caching Content-Length: 325 (the content contains a default page to display if the user-agent is not able to follow the link) <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://developer.mozilla.org/">here</a>.</p> <hr> <address>Apache/2.2.3 (Red Hat) Server at developer.mozilla.org Port 80</address> </body></html>
- Сообщение о том, что запрашиваемый ресурс не существует:
HTTP/1.1 404 Not Found Date: Sat, 09 Oct 2010 14:33:02 GMT Server: Apache Last-Modified: Tue, 01 May 2007 14:24:39 GMT ETag: "499fd34e-29ec-42f695ca96761;48fe7523cfcc1" Accept-Ranges: bytes Content-Length: 10732 Content-Type: text/html <!DOCTYPE html... (contains a site-customized page helping the user to find the missing resource)
Постоянные соединения
Постоянные соединения появились в HTTP/1.1 версии. Они позволяют передавать несколько запросов по одному и тому же TCP соединению (или по любому другому транспорту, в случае если не используется TCP/IP). У этой функции есть несколько преимуществ:
- Благодаря тому, что соединение может быть использовано повторно, запросы можно объединить в один ( HTTP pipelining ), что при отправке поможет уменьшенить задержки.
- Уменьшение открытия и закрытия TCP соединений, сохраняет время CPU.
- Перегруженность сети снижается за счет уменьшение общего количества TCP пакетов (меньше открывающих и закрывающих TCP пакетов).
- У TCP стека появляется больше времени на диагностику перегруженности сети и соответствующие изменения окон отправки и получения данных.
- HTTP становится более адаптивным: цена проверки новой функции значительно уменьшается, так как получение ошибки от сервера не ведет к закрытию соединения.
Методы HTTP запроса
Методы запроса обозначают действие, которое должно быть произведено на сервере. Стандарт HTTP/1.1 определяет семь методов, а также позволяет добавлять другие методы. За последние годы несколько методов было добавлено , например WebDAV. Группа IETF HTTPbis Working Group в настоящее время работает тем, чтобы перечислить все методы в IANA регистре. Если сервер получает метод, который он не знает, он должен вернуть ответ 501 Not implemented ; Если он знает метод, но сконфигурирован не отвечать на него, то сервер должен вернуть 405 Method not allowed ответ. От сервера требуется поддержка двух методов: HEAD and GET; Все остальные не обязательны.
Две характерные семантики определены в стандарте и являются важными для веб разработчиков: безопасность ( safety ) и идемпотентность ( idempotent ) методов.
Безопасный метод
Безопасный метод это метод, который не оказывает влияние на сервер. Другими словами, это свойство метода означает, что он используется только лоя получения данных. Ниже перечислены безопасные HTTP методы, определеные в HTTP/1.1:
- GET, используется для получения информации идентифицированной по URI, переданной в запросе. Эта информация может генерироваться на лету или GET может содержать условие - любое из следующих условий устанавливается в HTTP заголовках - {{ httpheader("If-Modified-Since") }}, {{ httpheader("If-Unmodified-Since") }}, {{ httpheader("If-Match") }}, {{ httpheader("If-None-Match") }} или {{ httpheader("If-Range") }} . И в этом случае информация будет отправляться сервером исключительно при выполнении этих условий.
- HEAD, который идентичен GET , но не содержащий сообщения в теле запроса.
- Любой безопасный метод является идемпотентным.
- Не оказывать влияния , для метода GET значит, что он не должен использоваться для вызова какого-либо действия на сервере, например для создания ордера на сайте интернет магазина. Если же влияние на сервер необходимо, то должен использоваться не идемпотентный метод, такой как POST.
- Когда страница каким-либо скриптом на лету, механизм скрипта может генерировать страницу так , как будто бы она была запрошена в методе GET и затем разделять блок с данными. Это не вызывает проблем, пока метод GET, заимплементирован в скрипте как безопасный, но если же он оказывает влияние на сервер (например, вызывает создание ордера на сайте интернет магазина) метод HEAD также вызовет это действие. Веб разработчик должен убедиться, что оба метода GET and HEAD заимплементированны безопасно.
Идемпотентные методы
Идемпотентный метод это такой метод, который при отправке нескольких идентичных запросов оказывает такое же влияние на сервер, как и один запрос.
- HEAD и GET, как любые безопасные методы, также являются идемпотентными, так как не меняют сервер.
- PUT это способ загрузки нового ресурса на сервер. Если ресурс уже существует и отличается от загружаемого, то он будет перезаписан; если его не существует, то он будет создан.
- DELETE удаляет ресурс с сервера.
Другие методы
- POST используется для вызова какого-либо действия на сервере. Он оказывает влияние и может использоваться для вызова процедуры создания ордера, для изменения в базе данных, для публикации сообщения на форуме и т.д.
- OPTIONS это запрос на получение опций комуникации между клиентом и сервером. (через конечные прокси); Этот метод обычно посылается перед каждым пробным кросс-доменным запросом (preflighted cross-origin request), для того чтобы узнать безопано ли его делать.
Имеем в виду: Preflighted cross-origin requests / пробные кросс-доменные запросы не возможно сделать на серверах, которые не поддерживают метод OPTIONS.
- TRACE это своего рода пинг между клиентом и сервером (через конечные прокси).
Многие другие методы, такие как PROPFIND или PATCH определены в других стандартах RFCs IETF, такие как WebDAV.
Метод CONNECT определен в RFC 2817.
Методы HTTP запросов в HTML формах
В HTML, разные методы HTTP запросов могут быть указаны в {{ htmlattrxref("method", "form") }} атрибуте элемента {{ HTMLElement("form") }}, а так же в {{ htmlattrxref("formmethod", "input") }} элемента {{ HTMLElement("input") }} и элемента {{ HTMLElement("button") }}. Но не все HTTP методы могут использоваться в вышеуказаных атрибутах; только GET and POST методы доступны по HTML спецификации.
Коды HTTP ответа
Когда сервер отвечает на клиентский запрос, он отправляет трехзначный номер (код), указывающий на результат выполнения запроса. Эти коды можно разделить на три группы:
- Информационные (
1xx) - предварительные ответы. В большинстве случаев ни конечный пользователь, ни веб разработчик или веб мастер не обращают на них внимание. Наиболее распространенный ответ 100 Continue , указывает на то, что клиент должен продолжить отправку своего запроса.Имеем в виду: Информационные ответы не определены в версии HTTP/1.0, и соотвественно не должны содержаться в ответе при использовании этой версии протокола. - Успешные (
2xx) используются для безошибочно обработанных запросов. 200 OK ответ является одним из самых распространенных, но 206 Partial Content также можно часто увидеть при получении файлов или медиа данных таких как видео или аудио. - Перенаправление (
3xx) указывают на то, что запрошенный клиентом ресурс изменил свое месторасположение, и сервер не может передать его напрямую. Большинство из этих ответов содержит информацию о местоположении, в котором можно найти запрашиваемый ресурс; агенты (user-agents) часто получают ресурс по новому адресу без взаимодействия с пользователем. Наиболее растространенными ответами данного типа являются 301 Moved Permanently, указывающий на то, что URI , переданный в запросе, больше не является валидным и переехал в другое место, 302 Found говорит нам о том, что ресурс был временно перемещен в другое место.Имеем в виду: Вебмастерам рекомендуется устанавливать 301 Moved Permanently перенаправления, в случае изменения URI страниц, например во время реорганизации сайта. Это позволяет пользователям, использующим старые ссылки, находить нужные ресурсы, а так же сообщает поисковым системам и другим сервисам новые адреса ресурсов, чтобы они могли переместить туда свои метаданные. Также важно добавлять соответствующие заголовки кэша в 301 Moved Permanently в ответ, для того, чтобы данная информация кэшировалась на стороне клиента. Это помогает избежать ненужных запросов к оригинальной URI перед получением самого ресурса. - Клиентские ошибки (
4xx) указывает на то, что запрос отправленный клиентом либо не правильный или неполный, либо у клиента не достаточно прав, чтобы его выполнить. Самый распространенный ответ в этой группе 404 Not Found , который возвращается в случае, когда запрошенный URI не существует, но пользователь может увидеть и другие ответы, например, 400 Bad Request возвращается в случаях не валидного HTTP запроса (так как это не должно происходить и может указывать на баг в клиенте (user agent) или, что менее вероятно, на сервере ) или 403 Forbidden, возвращается когда клиент запрашивает существующий ресурс, но который запрещен для передачи (например содержание директории). - Серверные ошибки (
5xx) сообщают нам, что у сервера были проблемы с обработкой клиентского запроса. Двумя наиболее распространенными ответами являются 500 Internal Server Error, универсальный код, означающий ошибку на сервере или 503 Service Unavailable указывает на то, что сервер не может запроцессить запрос в связи с временной проблемой, например в случае выключенного сервиса на время обслуживания или же не работающей базы данных.
С остальными кодами веб девелопер не сталкивается , но люди разрабатывающие запросы с использованием функции XMLHTTPRequest могут увидеть и менее привычные коды ответа.
Подробнее о перенаправлении
Начиная с Gecko 9.0 {{ geckoRelease("9.0") }}, перенаправления (такие как 301 и 307) , которые указывают javascript: URI более не выполняются. Вместо этого используется bad connection ответ. Это позволяет избежать кросс-доменных скриптовых атак. Подробнее см. {{ bug(255119) }}.
HTTP headers
HTTP заголовки позволяют клиенту и серверу передавать дополнительную информацию в запросе и ответе. Заголовки запроса состоят из не чувствительных к регистру ключей, заканчивающихся двоеточием':', и следом их значением (без CRLF). Пробел перед значением ключа игнорируется.
Заголовки сгруппированы следующим образом:
- Общие заголовки
- Эти заголовки применяются к запросам и ответам, но не связанны с данными пересылаемыми в теле запроса. Они применяются только к передаваемому сообщению. Их всего несколько и новые не добавляются без изменения версии HTTP протокола. Исчерпывающий список для версии HTTP/1.1 : {{ httpheader("Cache-Control") }}, {{ httpheader("Connection") }}, {{ httpheader("Date") }}, {{ httpheader("Pragma") }}, {{ httpheader("Trailer") }}, {{ httpheader("Transfer-Encoding") }}, {{ httpheader("Upgrade") }}, {{ httpheader("Via") }} and {{ httpheader("Warning") }}.
- Заголовки запроса
- Эти заголовки содержат более точную информацию о запрашиваемом ресурсе или о самом клиенте. Среди них мы можем найти заголовки относящиеся к кэшу ( cache-related headers ), условия для метода GET, например {{ httpheader("If-Modified-Since") }}, пользовательская информация, такая как {{ httpheader("Accept-Language") }} или {{ httpheader("Accept-Charset") }} или информация касаемая клиентского приложения: {{ httpheader("User-Agent") }}. Новые заголовки нельзя официально добавить, без изменения версии HTTP протокола. Однако, обычным делом является добавление нового заголовка, в случае если сервер и клиент договорились о его значении. В таком случае клиент не должен подразумевать, что новые заголовки будут адекватно обрабатываться сервером; неизвестные заголовки обрабатываются как заголовки объекта entity headers.
- Заголовки ответа
- Эти заголовки дают информацию о возвращаемом ресурсе - его реальное расположение ({{ httpheader("Location") }}) или о самом сервере, например его имя и версия ({{ httpheader("Server") }}). Новые заголовки не могут быть добавлены без изменения версии HTTP протокола. Однако, обычным делом является добавление новых заголовков, в случае если сервер и клиент договорились об из значении. Правда в таком случае клиент не должен подразумевать, что новые заголовки будут адекватно обрабатываться сервером; неизвестные заголовки обрабатываются как заголовки объекта entity headers.
- Заголовки объекта
- Эти заголовки предоставляют информацию о теле объекта - длина ({{ httpheader("Content-Length") }}), хэш ({{ httpheader("Content-MD5") }}), или его MIME-тип ({{ httpheader("Content-Type") }}). Новые объектные заголовки можно добавлять без изменения версии HTTP протокола.
Заголовки могут быть также сгруппированы исходя из того как они обрабатываются средставми кэширования:
- End-to-end заголовки
- Эти заголовки должны быть переданы конечному получателю сообщения: серверу в запросе или клиенту в ответе. Такой вид заголовка не должен измениться при передаче , а также должен быть сохранен в кэше.
- Hop-by-hop заголовки
- Такие заголовки имеют смысл только для единого соединения и не должны передаваться или кэшироваться. Примеры подобных заголовков : {{ httpheader("Connection") }}, {{ httpheader("Keep-Alive") }}, {{ httpheader("Proxy-Authenticate") }}, {{ httpheader("Proxy-Authorization") }}, {{ httpheader("TE") }}, {{ httpheader("Trailers") }}, {{ httpheader("Transfer-Encoding") }} и {{ httpheader("Upgrade") }}. Учтите, что только заголовки типа hop-by-hop могут быть установлены хэдером {{ httpheader("Connection") }}.
Чтобы узнать больше о значении каждого хэдера, обратитесь к статье полный список HTTP заголовков (comprehensive list of HTTP headers).
Полезные заголовки запроса
Среди большого количества HTTP заголовков запроса, некоторые являются наиболее полезными. Если вы строите свой собственный запрос средствами XMLHTTPRequest или пишете расширение и посылаете пользовательские HTTP запросы через XPCOM, тогда вам необходимо обеспечить наличие заголовков, которые часто устанавливаются браузерами в соответствии с пользовательскими настройками.
- Контроль языка запрашиваемого ресурса
- Многие клиенты (user-agents), такие как Firefox, позволяет пользователям устанавливать настройки языка запрашиваемых ресурсов. Браузер устанавливает эту настройку в заголовке {{ httpheader("Accept-Language") }} . Хорошей практикой для веб разработчиков при построении HTTP запросов, является использование этого хэдера.
- Использование условного GET
- Кэширование это очень важный инструмент ускорения отображения веб страниц. Даже когда части страницы обновляются с использованием
XMLHTTPRequest: хорошей идеей будет использовать хэдер {{ httpheader("If-Modified-Since") }} (и аналогичные ему) для того, чтобы получать новый контент только в случае его изменения. Такой подход уменьшает нагрузку на сеть.
Полезные заголовки ответа
Конфигурация веб сервера является критической частью обеспечения хорошей производительности и оптимальной безопасности веб сайта. Среди многочисленных HTTP заголовков ответа сервера, некоторые являются весьма важными и обязательно должны быть настроены на сервере.
Запрет фрейминга ( Restricting framing )
Опасность применения атак с использованием кросс-доменного скриптинга (XSS) отбивают охоту использовать внешний контент внутри {{ HTMLElement("frame") }} или {{ HTMLElement("iframe") }}. Для минимизации риска в современных браузерах предусмотрен хэдер X-Frame-Options. Его установка в DENY, запрещает браузеру отображать ресурс внутри фрейма (frame). Использование этого заголовка с критическими ресурсами (содержащими важную информацию) уменьшит риск вызванный XSS атаками. Важно отметить, что этот заголовок не является единственным способом обезопаситься от XSS атак; существуют и другие техники, такие как Content Security Policies.
Сжатие
Минимизация количества передаваемых данных ускоряет отображение веб страницы. Хотя многие техники, такие как использование CSS Sprites, должны быть применены на самом сайте, сжатие данных устанавливается на уровне сервера. Если сжатие включено, ресурсы запрашиваемые клиентом с установленным хэдером {{ httpheader("Accept-Encoding") }} сжимаются используя соответствующий метод и отправляются с хэдером {{ httpheader("Content-Encoding") }}. В серверах Apache 2 эти установки делаются в mod_deflate модуле.
Контроль кэша
HTTP Кэширование это способ предотвратить получение того же ресурса несколько раз, если он не менялся. Конфигурация сервера корректными хэдерами позволяет клиенту кэшировать данные соответствующим образом. Для того, чтобы это сделать, убедитесь что:
- Каждый статический ресурс предоставляет {{ httpheader("Expires") }} хэдер в ответе и он установлен на далёкую будущую дату. Таким образом ресурс остается в кэше до тех пор, пока клиент не почистит его по своим причинам (например, при достижении предела размеров кэша).
Имеем в виду: При использовании Apache, настройки кэширования и устанавливаются в файле .htaccess при помощи инструкции ExpiresDefault:
ExpiresDefault "access plus 1 month". - Любой динамический ресурс предоставляет хэдер {{ httpheader("Cache-control") }}. Теоритически любой HTTP запрос сделанный через безопасные методы (GET или HEAD) или даже через идемпотентные (DELETE, PUT) может быть кэширован; но на практике нужно анализировать возможный негативный побочный эффект, к которому может привести кэширование.
Установка правильных MIME типов
MIME это способ сказать клиенту о типе передаваемого документа: расширение файла не имеет смысла в вебе. Поэтому настройка сервера для передачи правильных MIME типов с каждым документом очень важна: клиенты (user-agents) часто используют MIME-типы для определения действия, которое нужно совершить с полученным ресурсом.
- На Apache сервере, заматчить расширения на соответствующие MIME типы можно в файле .htaccess используя инструкцию
AddType, примерAddType image/jpeg jpg. - В случае пересылки ресурса не известного типа, многие серверы по умолчанию используют MIME тип
application/octet-stream; В целях безопасности, многие браузеры, такие как Firefox, не позволяют настроить пользовательское действие для подобных ресурсов и вынуждают пользователя сохранять их на диске для использования. Некоторые весьма распространенные случаи не корректной конфигурации серверов происходят с файлами следующих типов:-
Rar-закодированные файлы. В идеале было бы здорово иметь возможность установить реальный тип закодированных файлов; это часто не возможно ( так как сервер может и не знать типа файлов и они могут содержать несколько ресурсов разных типов) В таком случае настройте сервер так, чтобы он отправлял MIME тип
application/x-rar-compressedили некоторые пользователи не смогут определить нужное дейстие для этих файлов. -
Аудио и видео файлы. Только ресурсы с правильным MIME Типом будут распознаны и проиграны, используя элементы {{ HTMLElement("video") }} или {{ HTMLElement("audio") }} . Убедитесь, что вы используете правильные MIME типы для аудио и видео ресурсов.
-
Проприетарные типы файлов. Обращайте особое внимание на передачу файлов с проприетарными типами. Не забывайте добавить x-префикс к их типу; иначе особая обработка будет не возможна. Это особенно касается ресурсов, использующих Keyhole Markup Language, который должен передаваться как тип
application/vnd.google-earth.kml+xml для оптимального использования.
-
Сообщество
- Mozilla форумы... {{ DiscussionList("dev-web-development", "mozilla.dev.web.development") }}
Инструменты
Связанные темы
См. также
- Controlling DNS prefetching
- The HTTP pipelining FAQ
- HTTP cookies
- HTTP Headers
- Basic access authentication
- HTTP access control (CORS)
{{ languages( { "ja": "ja/HTTP"} ) }}