--- title: HTTP slug: Web/HTTP tags: - HTTP - Headers - NeedsTranslation - TopicStub translation_of: Web/HTTP ---

{{ HTTPSidebar }}

Hypertext Transfer Protocol (HTTP) เป็นโปรโตคอลในระดับชั้นแอพพลิเคชัน(application-layer) ที่ใช้สำหรับการจัดส่งเอกสารประเภท hypermedia อย่างเช่นเอกสาร HTML และถูกออกแบบมาเพื่อใช้งานในการติดต่อสื่อสารระหว่าง web browser กับ web server และสามารถนำไปใช้ในจุดประสงค์อื่น ๆ ได้ด้วย ซึ่งรูปแบบการสื่อสารของโปรโตคอล HTTP เป็นไปตามโมเดลการสื่อสารแบบเครื่องลูกข่าย-แม่ข่าย(client-server model) ที่เครื่องลูกข่ายจะสร้าง connection เพื่อส่ง request ไปยังเครื่องแม่ข่าย และรอจนกว่าจะได้ response กลับมาจากเครื่องแม่ข่าย นอกจากนั้น HTTP เป็นโปรโตคอลแบบ stateless protocol เป็นลักษณะที่เครื่องแม่ข่ายไม่มีการจัดเก็บข้อมูล(state) ใด ๆ ที่เกิดขึ้นระหว่าง request เพราะข้อมูลแต่ละ request สามารถทำความเข้าใจได้ในตัวมันเอง และเนื่องจาก HTTP เป็นโปรโตคอลที่ใช้งานในระดับชั้นแอพพลิเคชัน ซึ่งอยู่ในระดับชั้นที่สูงกว่าโปรโตคอลในระดับล่างอย่าง TCP/IP ที่อยู่ในระดับ transport layer มันจึงสามารถใช้รูปแบบการติดต่อสื่อสารที่มีความน่าเชื่อถือของโปรโตคอลต่าง ๆ ในระดับชั้น transport ได้ อย่างเช่น อาจจะเลือกใช้โปรโตคอล RUDP ที่มีความน่าเชื่อถือกว่า UDP ที่มีโอกาสสูญเสียข้อมูลไปโดยไม่รู้ตัวได้

Documentation

HTTP Headers
HTTP message headers ใช้ในการบรรยายเกี่ยวกับ resource หรือ พฤติกรรมของเครื่องแม่ข่าย(server) หรือ เครื่องลูกข่าย(client) การสร้าง HTTP header ขึ้นใช้งานเอง สามารถทำได้ด้วยการเติมอักษร "X-" นำหน้าชื่อ header ที่ต้องการ โดย Header มาตรฐานต่าง ๆ สามารถศึกษาเพิ่มเติมได้จาก IANA registry เนื้อหาต้นฉบับจะถูกนิยามไว้ใน RFC 4229 โดยมี IANA เป็นผู้ดูแลเกี่ยวกับการลงทะเบียนเพื่อเสนอ HTTP header รูปแบบใหม่
HTTP cookies
การทำงานของ cookie ได้มีการนิยามไว้โดย RFC 6265 โดยกระบวนการเกิดขึ้นหลังจากที่เครื่องแม่ข่ายได้รับ HTTP request แล้ว เครื่องแม่ข่ายจะสามารถส่ง header ชื่อ Set-Cookie ไปกับ response ให้กับเครื่องลูกข่าย หลังจากนั้นเมื่อใดก็ตามที่เครื่องลูกข่ายต้องการส่ง request ไปยังเครื่องแม่ข่าย ค่าของ cookie จะถูกส่งไปพร้อม request ด้วยเสมอ ในรูปแบบของ HTTP header ชื่อ Cookie นอกจากนั้นยังสามารถกำหนดวันและเวลาหมดอายุของ cookie และการจำกัดการเข้าถึง domain และ path ได้
Basic access authentication
ในบริบทของการติดต่อสื่อสารบนโปรโตคอล HTTP นั้น การพิสูจน์ตัวจริงแบบพื้นฐานเพื่อการเข้าถึง (basic access authentication) เป็นวิธีการสำหรับ HTTP user agent ในการ request ไปยังเครื่องแม่ข่ายที่ต้องมีการจัดเตรียมรหัสผู้ใช้งาน (username) และรหัสผ่าน (password) เพื่อใช้ในการพิสูจน์ตัวจริง
HTTP pipelining FAQ
HTTP/1.1 Pipelining FAQ
HTTP access control (CORS)
Cross-site HTTP requests are HTTP requests for resources from a different domain than the domain of the resource making the request.  For instance, a resource loaded from Domain A (http://domaina.example) such as an HTML web page, makes a request for a resource on Domain B (http://domainb.foo), such as an image, using the img element (http://domainb.foo/image.jpg).  This occurs very commonly on the web today — pages load a number of resources in a cross-site manner, including CSS stylesheets, images and scripts, and other resources.
Controlling DNS prefetching
Firefox 3.5 performs DNS prefetching.  This is a feature by which Firefox proactively performs domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth. This prefetching is performed in the background, so that the DNS is likely to already have been resolved by the time the referenced items are actually needed.  This reduces latency when, for example, the user actually clicks a link.
HTTP response codes
HTTP Response Codes indicate whether a specific HTTP requests has been successfully completed. Responses are grouped in five classes: informational responses, successful responses, redirections, client errors, and servers errors.

A brief history of HTTP

Since its original conception, as a protocol with one single method (GET) and returning only HTML pages, the HTTP protocol went through several revisions. The first documented version was HTTP/0.9 in 1991, corresponding to the original version. Very simple, it has a rudimentary search capability via the HTML {{ HTMLElement("isindex") }} element and an extension of the URL using the '?' character.

Then, in 1992, a version was published that became, with some minor changes, HTTP/1.0 (finalized in RFC 1945 in May 1996). One major improvement over the previous version was the ability to transmit files of different types, like images, videos, scripts, CSS documents, and so on, instead of only HTML files: this is achieved by using MIME types in conjunction with the Content-Type: header.

In 1995, the IETF  began developing a new version of HTTP, which would become HTTP/1.1. It quickly spread into wide usage, and it was officially standardized in 1997 in RFC 2068, with minor fixes in RFC 2616 two years later.

HTTP/1.1 brought the ability to reuse established connections for subsequent requests, greatly improving the performance of the protocol by lowering the latency between them; this is especially useful with complex HTML documents that need to fetch several subsequent files, like images or style sheets. It also brought the Host: header, which allows a single server, listening on a specific port, to receive requests for several websites; this paved the way for colocating numerous websites on one single server, greatly reducing the cost of hosting.

Since then, the HTTP protocol evolved by adding new headers, defining new behaviors without the need to fundamentally change the protocol. Unknown headers are simply ignored by servers or clients.

HTTP/1.1 is currently being revised by the IETF HTTPbis Working Group.

HTTP request methods

The request method indicates the action to be performed by the server. The HTTP/1.1 standard defines seven methods and allows other methods to be added later. Over the years, a few ones have been added in standards like WebDAV. The  IETF HTTPbis Working Group is currently working on an IANA registry to list them all. If a server receives a request method that it doesn't know, it must return a 501 Not implemented response; if it knows the method but is configured not to answer it, it must return a 405 Method not allowed response. Two methods are required to be supported: HEAD and GET; all others are optional.

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:

Notes:

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.

Other methods

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. See this StackExchange answer why other HTTP request methods are not allowed by the HTML specification.

Note: The choice of a GET or POST method for HTML forms is not neutral. Because the GET method is a safe method, it should be used only in cases where no side-effect is expected; e.g., it shouldn't be used to transmit an order, as this order is a side-effect. In all cases where such side-effects are expected, the POST method should be used.

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:

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 be 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 can 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 CSP frame-ancestors directive. By setting it with the value 'none', 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.

Note: Be aware that not all data formats can be efficiently compressed. Already-compressed media data, like JPEG images or most audio and video formats, do not shrink using another pass of compression. In fact, they often become larger due to the overhead of the compression method. It is important not to try to compress these resource types any further; there is no advantage in size and the compression/decompression mechanism is resource-intensive.

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:

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.

Note:

See also

{{ languages( { "ja": "ja/HTTP"} ) }}