{{ 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; Все остальные не обязательны.
Two specific semantics are defined in the standard and are crucial for web developers: the safety property and the idempotent property.
Safe methods
A safe method is a method that doesn't have any side-effects on the server. In other words, this property means that the method must be used only for retrieval of data. The safe HTTP methods defined in HTTP/1.1 are:
- GET, used to retrieve information identified by the request URI. This information may be generated on the fly or the GET may be conditional if any of the {{ httpheader("If-Modified-Since") }}, {{ httpheader("If-Unmodified-Since") }}, {{ httpheader("If-Match") }}, {{ httpheader("If-None-Match") }} or {{ httpheader("If-Range") }} HTTP headers are set. In that latter case the information is only sent back if all the conditions are fulfilled.
- HEAD, which is identical to GET but without the message body sent.
- Any safe method is also idempotent.
- Not having any side-effects means, for the GET method, that it must not be used to trigger an action outside the server, like an order in an e-commerce site. If a side-effect is wanted, a non-idempotent method should be used, like POST.
- When a page is generated on the fly by a script, the script engine may calculate the page as if it was requested by a GET and then strip the data block. This does not cause problem as long as the GET as implemented in the script is safe, but if it has any side-effects (like triggering an order on an e-commerce site), the HEAD method will trigger it too. It is up to the web developer to ensure that both the GET and HEAD method are safely implemented.
Idempotent methods
An idempotent method is a method such that the side-effects on the server of several identical requests with the method are the same as the side-effects of one single request.
- HEAD and GET, like any safe method, are also idempotent, as a safe method doesn't have side-effects on the server.
- PUT is the way to upload a new resource on the server. If the resource already exists and is different, it is replaced; if it doesn't exist, it is created.
- DELETE removes a resource from the server.
Other methods
- POST is the way to trigger an action on the server. It has side-effects and can be used to trigger an order, to modify a database, to post a message in a forum, and so on.
- OPTIONS is a request for communication options available on the chain between the client and the server (through eventual proxies); this method is typically sent before any preflighted cross-origin request, in order to know whether it is safe to do it.
Note: Preflighted cross-origin requests cannot be done on servers which don't allow or support the OPTIONS method.
- TRACE is a kind of ping between the client and the server (through eventual proxies).
Many more methods, such as PROPFIND or PATCH are defined in other standards-track RFCs of the IETF, like WebDAV.
The CONNECT method is defined in RFC 2817.
HTTP Requests Methods in HTML Forms
In HTML, different HTTP request methods can be specified in the {{ htmlattrxref("method", "form") }} attribute of the {{ HTMLElement("form") }} element, but also to the {{ htmlattrxref("formmethod", "input") }} of the {{ HTMLElement("input") }} and {{ HTMLElement("button") }} elements. But not all HTTP methods can be used with these attributes; only GET and POST method are allowed by the HTML specification.
HTTP response codes
When answering a client request, the server sends back a three-digit number indicating whether the request was successfully processed. These codes can be grouped in five categories:
- Informational responses (of the form
1xx) are provisional responses. Most of the time neither the end user, nor the web developer or webmaster should have to bother with these. The most common is the 100 Continue response, indicating that the client should continue to send its request.Note: No information response codes were defined in the HTTP/1.0, and therefore they must not be sent back when this version of the protocol is used. - Success responses (of the form
2xx) are for successfully processed requests. The 200 OK response is by far the most common of these responses, but the 206 Partial Content is also often seen when fetching a file or some media data like video or audio. - Redirection responses (of the form
3xx) indicate that the resource that the client requested has moved and the server is not able to serve it directly. Most of these responses contain some location information telling where to find the requested resource; user-agents often then retrieve it without further user interaction. The most common responses of this type are 301 Moved Permanently, indicating that the URI given is no longer valid and has been moved to another place, and 302 Found which indicates that the resource has been temporarily moved to another place.Note: For webmasters, it is recommended to set up a 301 Moved Permanently redirection when moving pages to another URI, during a site reorganization for example. That allows users following links to still reach the resource and it also teaches search engines and other services the new location of the resource, so that they can transfer their metadata to it. It is also important to add adequate cache headers to the 301 Moved Permanently response so that this information is cached by the client and prevents it from making unnecessary requests to the original URI prior to fetching the resource itself. - Client error responses (of the form
4xx) indicate that the request sent by the client is either invalid, incomplete, or doesn't have enough rights to be performed. The most common such response is 404 Not Found which is sent back when the URI requested doesn't exist, but a few others are often presented to the end user, like 400 Bad Request sent when the request isn't a valid HTTP request (as this shouldn't happen but may indicate a bug into the user agent or, less likely, the server) or 403 Forbidden, sent when the client request a resource that does exist but isn't allowed to be transmitted (like a directory content). - Server error responses (of the form
5xx) indicate that the server had a problem handling the valid client request. The two most common such responses are 500 Internal Server Error, a generic error code indicating a bug in the server or 503 Service Unavailable indicating that the server cannot process the request due to a temporary problem, like a disabled service for maintenance purposes or the non-availability of a database.
A web developer shouldn't encounter many other response codes, but people building requests using the XMLHTTPRequest function may hit less usual response codes.
More on redirection responses
Starting in Gecko 9.0 {{ geckoRelease("9.0") }}, redirections (such as 301 and 307) that specify a javascript: URI are no longer performed. Instead, a bad connection error is presented. This helps avoid cross-site scripting attacks. See {{ bug(255119) }} if you want more details.
HTTP headers
HTTP headers allow the client and the server to pass additional information with the request or the response. A request header consists of its case-insensitive name followed by a colon ':', then by its value (without CRLF in it). Leading white space before the value is ignored.
Headers are grouped according the context in which they may appear:
- General headers
- These headers apply to both requests and responses but are unrelated to the data eventually transmitted in the body. They therefore apply only to the message being transmitted. There are only a few of them and new ones cannot been added without increasing the version number of the HTTP protocol. The exhaustive list for HTTP/1.1 is {{ httpheader("Cache-Control") }}, {{ httpheader("Connection") }}, {{ httpheader("Date") }}, {{ httpheader("Pragma") }}, {{ httpheader("Trailer") }}, {{ httpheader("Transfer-Encoding") }}, {{ httpheader("Upgrade") }}, {{ httpheader("Via") }} and {{ httpheader("Warning") }}.
- Request headers
- These headers give more precise information about the resource to be fetched or about the client itself. Among them one find cache-related headers, transforming a GET method in a conditional GET, like {{ httpheader("If-Modified-Since") }}, user-preference information like {{ httpheader("Accept-Language") }} or {{ httpheader("Accept-Charset") }} or plain client information like {{ httpheader("User-Agent") }}. New request headers cannot officially be added without increasing the version number of the HTTP protocol. But, it is common for new request headers to be added if both the server and the client agree on their meaning. In that case, a client should not assume that they will be handled adequately by the server; unknown request headers are handled as entity headers.
- Response headers
- These headers give more information about the resource sent back, like its real location ({{ httpheader("Location") }}) or about the server itself, like its name and version ({{ httpheader("Server") }}). New response headers cannot be added without increasing the version number of the HTTP protocol. But, it is common for new response headers to be added if both the server and the client agree on their meaning. In that case, a server should not assume that they will be handled adequately by the client ; unknown response headers are handled as entity headers.
- Entity headers
- These headers give more information about the body of the entity, like its length ({{ httpheader("Content-Length") }}), an identifying hash ({{ httpheader("Content-MD5") }}), or its MIME-type ({{ httpheader("Content-Type") }}). New entity headers can be added without increasing the version number of the HTTP protocol.
Headers can also be grouped according to how caching and non-caching proxies handle them:
- End-to-end headers
- These headers must be transmitted to the final recipient of the message; that is, the server for a request message or the client for a response message. Such a header means that intermediate proxies must retransmit it unmodified and also that caches must store it.
- Hop-by-hop headers
- These headers are meaningful only for a single transport-level connection and must not be retransmitted by proxies or cached. Such headers are: {{ httpheader("Connection") }}, {{ httpheader("Keep-Alive") }}, {{ httpheader("Proxy-Authenticate") }}, {{ httpheader("Proxy-Authorization") }}, {{ httpheader("TE") }}, {{ httpheader("Trailers") }}, {{ httpheader("Transfer-Encoding") }} and {{ httpheader("Upgrade") }}. Note that only hop-by-hop headers may be set using the {{ httpheader("Connection") }} general header.
In order to learn about the specific semantic of each header, see its entry in the comprehensive list of HTTP headers.
Useful request headers
Among the numerous HTTP request headers, several are especially useful when set correctly. If you are building your own requests, by using XMLHTTPRequest or when writing an extension and sending custom HTTP requests via XPCOM, then it is important to ensure the presence of headers that are often set by browsers based on the preferences of the user.
- Controlling the language of the resource
- Most user-agents, like Firefox, allow the user to set a preference for the language for receiving a resource. The browser translate this into an {{ httpheader("Accept-Language") }} header. It is good practice for web developers, when building specific HTTP requests, to include such a header too.
- Using conditional GET
- Caching is a major tool to accelerate the display of web pages. Even when parts of a webpage are refreshed via an
XMLHTTPRequest:, it is a good idea to use the {{ httpheader("If-Modified-Since") }} header (and other similar ones) in order to fetch the new content only if it has changed. This approach lowers the burden on the network.
Useful response headers
The configuration of a web server is a critical part to ensure good performance and optimal security of a web site. Among the numerous HTTP response headers, several are of specific importance and should be configured on the server
Restricting framing
Several cross-site scripting (XSS) attacks take advantage of the ability to put third-party content inside an {{ HTMLElement("frame") }} or {{ HTMLElement("iframe") }}. In order to mitigate that risk, modern browsers have introduced the X-Frame-Options: response header. By setting it with the value DENY, it prevents the browser from displaying this resource inside of a frame. Using it on critical resources (like those containing a formularies or critical information) will reduce the risk caused by XSS attacks. Note that this specific HTTP response header is not the only way to mitigate XSS risks; other techniques, like setting some Content Security Policies, may be helpful too.
Compression
Minimizing the amount of data transferred accelerates the display of a web page. Though most techniques, like CSS Sprites, should be applied on the site itself, compression of data must be set at the web server level. If set, resources requested by the client with an {{ httpheader("Accept-Encoding") }} request header are compressed using the appropriate method and sent back with a {{ httpheader("Content-Encoding") }} response header. Setting these in Apache 2 servers is done by using the mod_deflate module.
Controlling cache
HTTP Caching is a technique that prevents the same resource from being fetched several times if it hasn't change. Configuring the server with the correct response headers allows the user-agent to adequately cache the data. In order to do that, be sure that:
- Any static resource provides an {{ httpheader("Expires") }} response header that is set to far in the future. That way, the resource may stay in the cache until the user-agent flushes it for its own reasons (like reaching its cache size limit).
Note: On Apache, use the ExpiresDefault directive in your .htaccess to define a relative expires:
ExpiresDefault "access plus 1 month". - Any dynamic resource provides a {{ httpheader("Cache-control") }} response header. Theoretically, any HTTP request done through a safe method (GET or HEAD) or even through a solely idempotent one (DELETE, PUT) may be cached; but in practice careful study is needed to determine if the caching of the response may lead to inappropriate side-effects.
Setting the correct MIME types
The MIME type is the mechanism to tell the client the kind of document transmitted: the extension of a file name has no meaning on the web. It is therefore important that the server is correctly set up so that the correct MIME type is transmitted with each document: user-agents often use this MIME-type to determine what default action to do when a resource is fetched.
- On Apache, one can match file extensions with a given MIME type in the .htaccess using the
AddTypetype directive likeAddType image/jpeg jpg. - Most web servers send unknown-type resources using the default
application/octet-streamMIME type; for security reasons, most browsers, like Firefox, do not allow setting a custom default action for such resources and force the user to store it to disk in order to use it. Some common cases of often incorrectly configured servers happens for the following file types:-
Rar-encoded files. The ideal would be to be able to set the real type of the encoded files; this often is not possible (as it may not be known to the server and these files may contains several resource of different types). In that case, configure the server to send the
application/x-rar-compressedMIME type or some users won't be able to define a useful default action for them. -
Audio and video files. Only resources with the proper MIME Type will be recognized and played, using a {{ HTMLElement("video") }} or {{ HTMLElement("audio") }} elements. Be sure to use the correct MIME type for audio and video resources.
-
Proprietary file types. Pay special attention when serving a proprietary file type. Be sure not to forget to add an x-prefixed type for it; otherwise, special handling won't be possible. This is especially true with resources using the Keyhole Markup Language, which should be served as
application/vnd.google-earth.kml+xmlfor an optimal user experience.
-
Community
- View Mozilla forums... {{ DiscussionList("dev-web-development", "mozilla.dev.web.development") }}
Tools
Related Topics
See also
- Controlling DNS prefetching
- The HTTP pipelining FAQ
- HTTP cookies
- HTTP Headers
- Basic access authentication
- HTTP access control (CORS)
{{ languages( { "ja": "ja/HTTP"} ) }}