Http 简明教程
HTTP - Quick Guide
超文本传输协议(HTTP)是一种用于分布式、协作式、超媒体信息系统的应用程序层协议。自1990年以来,它一直是万维网(即互联网)数据通信的基础。HTTP是一种通用的无状态协议,还可以通过扩展其请求方法、错误代码和标头来用于其他目的。
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This is the foundation for data communication for the World Wide Web (ie. internet) since 1990. HTTP is a generic and stateless protocol which can be used for other purposes as well using extension of its request methods, error codes and headers.
超文本传输协议(HTTP)是一种基于 TCP/IP 的通信协议,用于在万维网上传输数据(HTML 文件、图像文件、查询结果等)。默认端口是 TCP 80,但可以使用其他端口。它为计算机之间相互通信提供了一种标准化方式。HTTP 规范规定了客户端如何构建数据请求并将其发送到服务器,以及服务器如何响应这些请求。
Basically, HTTP is an TCP/IP based communication protocol, which is used to deliver data (HTML files, image files, query results etc) on the World Wide Web. The default port is TCP 80, but other ports can be used. It provides a standardized way for computers to communicate with each other. HTTP specification specifies how clients request data will be constructed and sent to the serve, and how servers respond to these requests.
Basic Features
以下三个基本功能使 HTTP 成为一个简单但功能强大的协议:
There are following three basic features which makes HTTP a simple but powerful protocol:
-
HTTP is connectionless: The HTTP client ie. browser initiates an HTTP request and after a request is made, the client disconnects from the server and waits for a response. The server process the request and re-establish the connection with the client to send response back.
-
HTTP is media independent: This means, any type of data can be sent by HTTP as long as both the client and server know how to handle the data content. This is required for client as well as server to specify the content type using appropriate MIME-type.
-
HTTP is stateless: As mentioned above, HTTP is a connectionless and this is a direct result that HTTP is a stateless protocol. The server and client are aware of each other only during a current request. Afterwards, both of them forget about each other. Due to this nature of the protocol, neither the client nor the browser can retain information between different request across the web pages.
Basic Architecture
下图显示了 web 应用程序的一个非常基本的架构,并描绘了 HTTP 所处的位置:
Following diagram shows a very basic architecture of a web application and depicts where HTTP sits:
HTTP 协议是一种基于客户端/服务器架构的请求/响应协议,其中 web 浏览器、网络机器人和搜索引擎等充当 HTTP 客户端,而 Web 服务器充当服务器。
The HTTP protocol is a request/response protocol based on client/server based architecture where web browser, robots and search engines, etc. act like HTTP clients and Web server acts as server.
Client
HTTP 客户端以请求方法、URI 和协议版本的形式将请求发送到服务器,然后是包含请求修饰符、客户端信息和可能通过 TCP/IP 连接传递的主体内容的 MIME 类似消息。
The HTTP client sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible body content over a TCP/IP connection.
Server
HTTP 服务器以状态行响应,其中包括消息的协议版本和成功或错误代码,然后是包含服务器信息、实体元信息和可能的实体正文内容的类似 MIME 的消息。
The HTTP server responds with a status line, including the message’s protocol version and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body content.
HTTP - Parameters
本章将列出一些重要的 HTTP 协议参数及其在通信中使用的语法。例如,日期格式、URL 格式等。在编写 HTTP 客户端或服务器程序时,这将帮助你构建请求和响应消息。在解释 HTTP 请求和响应的消息结构时,你将在后续章节中看到这些参数的完整用法。
This chapter is going to list down few of the important HTTP Protocol Parameters and their syntax in a way they are used in the communication. For example, format for date, format of URL etc. This will help you in constructing your request and response messages while writing HTTP client or server programs. You will see complete usage of these parameters in subsequent chapters while explaining message structure for HTTP requests and responses.
HTTP Version
HTTP 使用编号方案来表示协议的版本。HTTP 消息的版本由第一行中的 HTTP 版本字段指示。以下是指定 HTTP 版本号的一般语法:
HTTP uses a <major>.<minor> numbering scheme to indicate versions of the protocol. The version of an HTTP message is indicated by an HTTP-Version field in the first line. Here is the general syntax of specifying HTTP version number:
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Uniform Resource Identifiers (URI)
统一资源标识符 (URI) 是格式简单、不区分大小写的字符串,其中包含名称、位置等,用于标识资源,例如网站、web 服务等。用于 HTTP 的 URI 的一般语法如下:
Uniform Resource Identifiers (URI) is simply formatted, case-insensitive string containing name, location etc to identify a resource, for example a website, a web service etc. A general syntax of URI used for HTTP is as follows:
URI = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
如果 {} 中的内容为空或未给出,则假定 HTTP 端口为 80,而空 {} 等效于 “/”。{} 和 {} 集之外的字符等效于它们的 ""%" HEX HEX" 编码。
Here if the port is empty or not given, port 80 is assumed for HTTP and an empty abs_path is equivalent to an abs_path of "/". The characters other than those in the reserved and unsafe sets are equivalent to their ""%" HEX HEX" encoding.
Date/Time Formats
所有HTTP日期/时间戳都必须以格林尼治标准时间(GMT)表示,无一例外。HTTP应用程序可以使用以下三种日期/时间戳表示形式中的任何一种:
All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception. HTTP applications are allowed to use any of the following three representations of date/time stamps:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
Character Sets
你使用字符集来指定客户端首选的字符集。多个字符集可以用逗号分隔。如果未指定值,则默认为 US-ASCII。
You use character set to specify the character sets that the client prefers. Multiple character sets can be listed separated by commas. If a value is not specified, the default is US-ASCII.
Content Encodings
内容编码值表示在通过网络传递内容之前已使用编码算法来对内容进行编码。内容编码主要用于允许对文档进行压缩或以其他有用的方式转换,而不会丢失标识。
A content ecoding values indicate an encoding algorithm has been used to encode the content before passing it over the network. Content codings are primarily used to allow a document to be compressed or otherwise usefully transformed without losing the identity.
所有内容编码值都不区分大小写。HTTP/1.1 在 Accept-Encoding 和 Content-Encoding 头字段中使用内容编码值,我们将在后续章节中看到。
All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding and Content-Encoding header fields which we will see in subsequent chapters.
Media Types
HTTP 使用 Content-Type 和 Accept 标头字段中的互联网媒体类型,以提供开放且可扩展的数据类型和类型协商。所有媒体类型值都向互联网号码分配机构 (IANA) 注册。以下是指定媒体类型的通用语法:
HTTP uses Internet Media Types in the Content-Type and Accept header fields in order to provide open and extensible data typing and type negotiation. All the Media-type values are registered with the Internet Assigned Number Authority ((IANA). Following is a general syntax to specify media type:
media-type = type "/" subtype *( ";" parameter )
类型、子类型和参数属性名称不区分大小写。
The type, subtype, and parameter attribute names are case- insensitive.
Language Tags
HTTP 在 Accept-Language 和 Content-Language 字段中使用语言标签。语言标签由 1 个或多个部分组成:一个主要语言标签和一个可能为空子标签的系列:
HTTP uses language tags within the Accept-Language and Content-Language fields. A language tag is composed of 1 or more parts: A primary language tag and a possibly empty series of subtags:
language-tag = primary-tag *( "-" subtag )
标签内不允许有空格,所有标签不区分大小写。
White space is not allowed within the tag and all tags are case- insensitive.
HTTP - Messages
HTTP 基于客户端-服务器架构模型和一个无状态的请求/响应协议,该协议通过在可靠的 TCP/IP 连接上交换消息来操作。
HTTP is based on client-server architecture model and a stateless request/response protocol that operates by exchanging messages across a reliable TCP/IP connection.
HTTP “客户端”是为发送一个或多个 HTTP 请求消息的目的而建立到服务器的连接的程序(Web 浏览器或任何其他客户端)。HTTP “服务器”是一个程序(通常是 Web 服务器,如 Apache Web Server 或 Internet Information Services IIS 等),它接受连接以通过发送 HTTP 响应消息来处理 HTTP 请求。
An HTTP "client" is a program (Web browser or any other client) that establishes a connection to a server for the purpose of sending one or more HTTP request messages. An HTTP "server" is a program ( generally a web server like Apache Web Server or Internet Information Services IIS etc. ) that accepts connections in order to serve HTTP requests by sending HTTP response messages.
HTTP 使用统一资源标识符 (URI) 来识别给定资源并建立连接。一旦建立连接, HTTP messages 将以类似于互联网邮件 [RFC5322] 和多用途互联网邮件扩展 (MIME) [RFC2045] 所用格式传递。这些消息由从客户端到服务器的 requests 和从服务器到客户端的 responses 组成,其将具有以下格式:
HTTP makes use of the Uniform Resource Identifier (URI) to identify a given resource and to establish a connection. Once connection is established, HTTP messages are passed in a format similar to that used by Internet mail [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) [RFC2045]. These messages are consisted of requests from client to server and responses from server to client which will have following format:
HTTP-message = <Request> | <Response> ; HTTP/1.1 messages
HTTP 请求和 HTTP 响应使用 RFC 822 的通用消息格式来传输所需数据。此通用消息格式由以下四个项目组成。
HTTP request and HTTP response use a generic message format of RFC 822 for transferring the required data. This generic message format consists of following four items.
A Start-line
Zero or more header fields followed by CRLF
An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
Optionally a message-body
以下部分将解释 HTTP 消息中使用的每个实体。
Following section will explain each of the entities used in HTTP message.
Message Start-Line
启动行将具有以下通用语法:
A start-line will have following generic syntax:
start-line = Request-Line | Status-Line
我们将在讨论 HTTP 请求和 HTTP 响应消息时分别讨论请求行和状态行。现在让我们看一看请求和响应中的启动行的示例:
We will discuss Request-Line and Status-Line while discussing HTTP Request and HTTP Response messages respectively. For now let’s see the examples of start line in case of request and response:
GET /hello.htm HTTP/1.1 (This is Request-Line sent by the client)
HTTP/1.1 200 OK (This is Status-Line sent by the server)
Header Fields
HTTP 标头字段提供有关请求或响应或消息正文中发送的对象的所需信息。有以下四种类型的 HTTP 消息标头:
HTTP deader fields provide required information about the request or response, or about the object sent in the message body. There are following four types of HTTP message headers:
-
General-header: These header fields have general applicability for both request and response messages.
-
Request-header: These header fields are applicability only for request messages.
-
Response-header: These header fields are applicability only for response messages.
-
Entity-header: These header fields define metainformation about the entity-body or, if no body is present
所有上述标头都遵循相同的通用格式,每个标头字段都包含一个名称,后跟冒号 ( : ) 和字段值,如下所示:
All the above mentioned headers follow the same generic format and each of the header field consists of a name followed by a colon (:) and the field value as follows:
message-header = field-name ":" [ field-value ]
以下是各種標頭欄位的範例:
Following are the examples of various header fields:
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
Message Body
訊息主體部分對於 HTTP 訊息來說是可選的,但是如果可用,那麼就會用於傳遞與要求或回應相關的實體主體。如果實體主體相關,則通常 Content-Type 及 * Content-Length* 標頭行會指定與主體相關的性質。
The message body part is optional for an HTTP message but if it is available then it is used to carry the entity-body associated with the request or response. If entity body is associated then usually Content-Type and * Content-Length* headers lines specify the nature of the body associated.
訊息主體用於傳遞實際 HTTP 要求資料(包括表單資料、上傳資料等),以及由伺服器傳來的 HTTP 回應資料(包括檔案、影像等)。以下是訊息主體的簡單範例:
A message body is the one which carries actual HTTP request data (including form data and uploaded etc.) and HTTP response data from the server ( including files, images etc). Following is a simple content of a message body:
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
HTTP - Requests
HTTP 客户端以请求消息的形式向服务器发送 HTTP 请求,其中包含以下格式:
An HTTP client sends an HTTP request to a server in the form of a request message which includes following format:
A Request-line
Zero or more header (General|Request|Entity) fields followed by CRLF
An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
Optionally a message-body
以下部分将解释 HTTP 消息中使用的每个实体。
Following section will explain each of the entities used in HTTP message.
Message Request-Line
请求行以方法标记开头,后跟请求 URI 和协议版本,并以 CRLF 结尾。各元素之间由空格 SP 字符分隔。
The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by space SP characters.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
讓我們討論要求行中提到的每個部分。
Let’s discuss each of the part mentioned in Request-Line.
Request Method
要求 Method 指示所要對所給 Request-URI 識別的資源所執行的操作。該操作區分大小寫且應始終以大寫字母表示。以下為 HTTP/1.1 中支援的方法:
The request Method indicates the method to be performed on the resource identified by the given Request-URI. The method is case-sensitive ans should always be mentioned uppercase. Following are supported methods in HTTP/1.1
S.N. |
Method and Description |
1 |
GET The GET method is used to retrieve information from the given server using a given URI. Requests using GET should only retrieve data and should have no other effect on the data. |
2 |
HEAD Same as GET, but only transfer the status line and header section. |
3 |
POST A POST request is used to send data to the server, for example customer information, file upload etc using HTML forms. |
4 |
PUT Replace all current representations of the target resource with the uploaded content. |
5 |
DELETE Remove all current representations of the target resource given by URI. |
6 |
CONNECT Establish a tunnel to the server identified by a given URI. |
7 |
OPTIONS Describe the communication options for the target resource. |
8 |
TRACE Perform a message loop-back test along the path to the target resource. |
Request-URI
Request-URI 是统一资源标识符,用于标识对其应用请求的资源。下面是最常用的 URI 指定形式:
The Request-URI is a Uniform Resource Identifier and identifies the resource upon which to apply the request. Following are the most commonly used forms to specify an URI:
Request-URI = "*" | absoluteURI | abs_path | authority
S.N. |
Method and Description |
1 |
The asterisk * is used when HTTP request does not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily apply to a resource. For example:*OPTIONS * HTTP/1.1* |
2 |
The absoluteURI is used when HTTP request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, and return the response. For example:*GET [role="bare"]http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1* |
3 |
The most common form of Request-URI is that used to identify a resource on an origin server or gateway. For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines:*GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org* Note that the absolute path cannot be empty; if none is present in the original URI, it MUST be given as "/" (the server root) |
Request Header Fields
我們會在學習 HTTP 標頭欄位時,於獨立的一章節探討一般標頭和實體標頭。現在讓我們來看看什麼是要求標頭欄位。
We will study General-header and Entity-header in a separate chapter when we will learn HTTP header fields. For now let’s check what are Request header fields.
要求標頭欄位讓客戶端得以在要求中,另外傳遞一些有關要求以及客戶端本身的資訊給伺服器。這些欄位的行為如同要求修改器,且有以下重要的可用要求標頭欄位,可用於依需求使用。
The request-header fields allow the client to pass additional information about the request, and about the client itself, to the server. These fields act as request modifiers and there are following important Request-header fields available which can be used based on requirement.
-
Accept-Charset
-
Accept-Encoding
-
Accept-Language
-
Authorization
-
Expect
-
From
-
Host
-
If-Match
-
If-Modified-Since
-
If-None-Match
-
If-Range
-
If-Unmodified-Since
-
Max-Forwards
-
Proxy-Authorization
-
Range
-
Referer
-
TE
-
User-Agent
如果你要撰寫自己的自訂客戶端和 Web 伺服器,可以採用自訂欄位。
You can introduce your custom fields in case you are going to write your own custom Client and Web Server.
Request Message Examples
现在让我们将它们放在一起,以便从在 tutorialspoint.com 上运行的 Web 服务器中提取 hello.htm 页面以形成一个 HTTP 请求
Now let’s put it all together to form an HTTP request to fetch hello.htm page from the web server running on tutorialspoint.com
GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
在这里,我们没有向服务器发送任何请求数据,因为我们正在从服务器中提取一个 plan HTML 页面。连接是此处使用的通用标头,其余标头是请求标头。以下是一个更多示例,其中使用请求消息正文将表单数据发送到服务器:
Here we are not sending any request data to the server because we are fetching a plan HTML page from the server. Connection is a general-header used here and rest of the headers are request headers. Following is one more example where we send form data to the server using request message body:
POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
licenseID=string&content=string&/paramsXML=string
这里给定的 URL /cgi-bin/process.cgi 将用于处理已传递数据,相应地返回一个响应。在此, content-type 告诉服务器传递的数据是简单的 Web 表单数据, length 将是放入消息正文中的数据的实际长度。以下示例显示如何将 plan XML 传递给 Web 服务器:
Here given URL /cgi-bin/process.cgi will be used to process the passed data and accordingly a response will be retuned. Here content-type tells the server that passed data is simple web form data and length will be actual length of the data put in the message body. Following example shows how you can pass plan XML to your web server:
POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>
HTTP - Responses
在收到并解读请求消息后,服务器会使用 HTTP 响应消息进行响应:
After receiving and interpreting a request message, a server responds with an HTTP response message:
A Status-line
Zero or more header (General|Response|Entity) fields followed by CRLF
An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
Optionally a message-body
以下部分将解释 HTTP 消息中使用的每个实体。
Following section will explain each of the entities used in HTTP message.
Message Status-Line
状态行由协议版本后跟数字状态代码及其关联的文本短语组成。元素之间用空格 SP 字符分隔。
The Status-Line consisting of the protocol version followed by a numeric status code and its associated textual phrase. The elements are separated by space SP characters.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
让我们讨论状态行中提到的每个部分。
Let’s discuss each of the part mentioned in Status-Line.
HTTP Version
支持 HTTP 版本 1.1 的服务器将返回以下版本信息:
A server supporting HTTP version 1.1 will return following version information:
HTTP-Version = HTTP/1.1
Status Code
状态代码元素是 3 位整数,其中状态码的第一位定义了响应的类型,而最后两位没有分类作用。第一位有 5 个值:
The Status-Code element is a 3-digit integer where first digit of the Status-Code defines the class of response and the last two digits do not have any categorization role. There are 5 values for the first digit:
S.N. |
Code and Description |
1 |
1xx: Informational This means request received and continuing process. |
2 |
2xx: Success This means the action was successfully received, understood, and accepted. |
3 |
3xx: Redirection This means further action must be taken in order to complete the request. |
4 |
4xx: Client Error This means the request contains bad syntax or cannot be fulfilled |
5 |
5xx: Server Error The server failed to fulfill an apparently valid request |
HTTP 状态代码是可扩展的,并且不需要 HTTP 应用程序了解所有已注册状态代码的含义。列出了所有状态代码的清单,供你参考。
HTTP status codes are extensible and HTTP applications are not required to understand the meaning of all registered status codes. A list of all the status code has been given in a separate chapter for you reference.
Response Header Fields
我们将在单独的章节中学习通用标头和实体标头,届时我们将学习 HTTP 标头字段。现在,我们来看看响应标头字段是什么。
We will study General-header and Entity-header in a separate chapter when we will learn HTTP header fields. For now let’s check what are Response header fields.
响应标头字段允许服务器传递有关响应的附加信息,该信息无法放在状态行中。这些标头字段提供了有关服务器的信息,以及对请求 URI 所标识的资源的进一步访问。
The response-header fields allow the server to pass additional information about the response which cannot be placed in the Status- Line. These header fields give information about the server and about further access to the resource identified by the Request-URI.
-
Accept-Ranges
-
Age
-
ETag
-
Location
-
Proxy-Authenticate
-
Retry-After
-
Server
-
Vary
-
WWW-Authenticate
如果你打算编写自己的自定义 Web 客户端和服务器,则可以引入自定义字段。
You can introduce your custom fields in case you are going to write your own custom Web Client and Server.
Response Message Examples
现在,让我们全部放在一起,为从在 tutorialspoint.com 上运行的 Web 服务器获取 hello.htm 页的请求形成一个 HTTP 响应
Now let’s put it all together to form an HTTP response for a request to fetch hello.htm page from the web server running on tutorialspoint.com
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
以下是 HTTP 响应消息的一个示例,显示错误情况,因为 Web 服务器找不到请求的页面:
Following is an example of HTTP response message showing error condition when web server could not find requested page:
HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Connection: Closed
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
<title>404 Not Found</title>
</head>
<body>
<h1>Not Found</h1>
<p>The requested URL /t.html was not found on this server.</p>
</body>
</html>
以下是 HTTP 响应消息的一个示例,显示错误情况,因为 Web 服务器在给定的 HTTP 请求中遇到了错误的 HTTP 版本:
Following is an example of HTTP response message showing error condition when web server encountered a wrong HTTP version in given HTTP request:
HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: Closed
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
<title>400 Bad Request</title>
</head>
<body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<p>
<p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>
HTTP - Methods
下面定义了 HTTP/1.1 的常用方法集,并且可以根据要求扩展此方法集。这些方法名称区分大小写,并且必须使用大写字母。
The set of common methods for HTTP/1.1 is defined below and this set can be expanded based on requirement. These method names are case sensitive and they must be used in uppercase.
S.N. |
Method and Description |
1 |
GET The GET method is used to retrieve information from the given server using a given URI. Requests using GET should only retrieve data and should have no other effect on the data. |
2 |
HEAD Same as GET, but only transfer the status line and header section. |
3 |
POST A POST request is used to send data to the server, for example customer information, file upload etc using HTML forms. |
4 |
PUT Replace all current representations of the target resource with the uploaded content. |
5 |
DELETE Remove all current representations of the target resource given by URI. |
6 |
CONNECT Establish a tunnel to the server identified by a given URI. |
7 |
OPTIONS Describe the communication options for the target resource. |
8 |
TRACE Perform a message loop-back test along the path to the target resource. |
GET Method
GET 请求通过在请求的 URL 部分中指定参数从 Web 服务器检索数据。这是用于检索文档的主要方法。以下是一个简单的示例,它使用 GET 方法获取 hello.htm:
A GET request retrieves data from a web server by specifying parameters in the URL portion of the request. This is the main method used for document retrieval. Following is a simple example which makes use of GET method to fetch hello.htm:
GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
服务器对以上 GET 请求的响应如下:
The server response against the above GET request will be as follows:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
HEAD Method
HEAD 方法的功能类似于 GET,除了服务器以响应行和标头进行回复,但没有实体主体。以下是一个简单的示例,它使用 HEAD 方法获取有关 hello.htm 的标头信息:
The HEAD method is functionally like GET, except that the server replies with a response line and headers, but no entity-body. Following is a simple example which makes use of HEAD method to fetch header information about hello.htm:
HEAD /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
以下将是对上述 GET 请求的服务器响应:
Following will be a server response against the above GET request:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed
你可能会注意到,此处服务器在标头之后不会发送任何数据。
You can notice that here server does not send any data after header.
POST Method
当你想要向服务器发送某些数据(例如文件更新、表单数据等)时,请使用 POST 方法。以下是一个简单的示例,它使用 POST 方法向服务器发送表单数据,该数据将由 process.cgi 处理,最后返回响应:
The POST method is used when you want to send some data to the server, for example file update, form data etc. Following is a simple example which makes use of POST method to send a form data to the server which will be processed by a process.cgi and finally a response will be returned:
POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 88
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>
服务器端脚本 process.cgi 处理传递的数据并发送以下响应:
Server side script process.cgi process the passed data and send following response:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed
<html>
<body>
<h1>Request Processed Successfully</h1>
</body>
</html>
PUT Method
PUT 方法用于请求服务器在给定 URL 指定的位置存储包含的实体主体。以下示例请求服务器将给定的实体主体保存在 hello.htm 服务器的根目录中:
The PUT method is used to request the server to store the included entity-body at a location specified by the given URL. The following example request server to save the given entity-body in hello.htm at the root of the server:
PUT /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
服务器将把给定的实体主体存储在 hello.htm 文件中,并向客户端发送以下响应:
The server will store given entity-body in hello.htm file and will send following response back to the client:
HTTP/1.1 201 Created
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed
<html>
<body>
<h1>The file was created.</h1>
</body>
</html>
DELETE Method
DELETE 方法用于请求服务器删除由给定的 URL 指定位置的文件。以下示例请求服务器删除位于服务器根目录中的给定文件 hello.htm :
The DELETE method is used to request the server to delete file at a location specified by the given URL. The following example request server to delete the given file hello.htm at the root of the server:
DELETE /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive
服务器将删除提到的文件 hello.htm 并向客户端发回以下响应:
The server will delete mentioned file hello.htm and will send following response back to the client:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed
<html>
<body>
<h1>URL deleted.</h1>
</body>
</html>
CONNECT Method
CONNECT 方法由客户端用于通过 HTTP 在网络中建立与网络服务器的连接。以下示例请求与运行在 tutorialspoint.com 主机上的网络服务器建立连接:
The CONNECT method is used by the client to establish a network connection to a web server over HTTP. The following example request a connection with a web server running on host tutorialspoint.com:
CONNECT www.tutorialspoint.com HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
同服务器建立了连接并向客户端发回了以下响应:
The connection is established with the server and following response is sent back to the client:
HTTP/1.1 200 Connection established
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
OPTIONS Method
OPTIONS 方法由客户端用于查找网络服务器支持的 HTTP 方法和其他选项。客户端可以为 OPTIONS 方法指定一个 URL,或一个星号 (*) 来引用整个服务器。以下示例请求 tutorialspoint.com 上运行的网络服务器支持的方法列表:
The OPTIONS method is used by the client to find out what are the HTTP methods and other options supported by a web server. The client can specify a URL for the OPTIONS method, or an asterisk (*) to refer to the entire server. The following example request a list of methods supported by a web server running on tutorialspoint.com:
OPTIONS * HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
服务器将根据服务器的当前配置发送信息,例如:
The server will send information based on the current configuration of the server, for example:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: httpd/unix-directory
TRACE Method
TRACE 方法用于对 HTTP 请求的内容进行回显,将其返回给请求者,这可用于在开发时进行调试。以下示例显示了 TRACE 方法的用法:
The TRACE method is used to eacho the contents of an HTTP Request back to the requester which can be used for debugging purpose at the time of development. The following example shows the usage of TRACE method:
TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
服务器将根据上述请求发送以下消息作为响应:
The server will send following message in response of the above request:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Type: message/http
Content-Length: 39
Connection: Closed
TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
HTTP - Status Codes
服务器响应中的状态代码元素是一个 3 位整数,状态代码的第一位定义了响应的类型,而后两位没有分类作用。第一位有 5 个值:
The Status-Code element in a server response, is a 3-digit integer where first digit of the Status-Code defines the class of response and the last two digits do not have any categorization role. There are 5 values for the first digit:
S.N. |
Code and Description |
1 |
1xx: Informational This means request received and continuing process. |
2 |
2xx: Success This means the action was successfully received, understood, and accepted. |
3 |
3xx: Redirection This means further action must be taken in order to complete the request. |
4 |
4xx: Client Error This means the request contains bad syntax or cannot be fulfilled |
5 |
5xx: Server Error The server failed to fulfill an apparently valid request |
HTTP 状态代码是可以扩展的,而 HTTP 应用程序不需要理解所有已注册状态代码的含义。以下是所有状态代码的列表。
HTTP status codes are extensible and HTTP applications are not required to understand the meaning of all registered status codes. Following is a list of all the status code.
1xx: Information
Message: |
Description: |
100 Continue |
Only a part of the request has been received by the server, but as long as it has not been rejected, the client should continue with the request |
101 Switching Protocols |
The server switches protocol |
2xx: Successful
Message: |
Description: |
200 OK |
The request is OK |
201 Created |
The request is complete, and a new resource is created |
202 Accepted |
The request is accepted for processing, but the processing is not complete |
203 Non-authoritative Information |
The information in the entity header is from a local or third-party copy, not from the original server. |
204 No Content |
A status code and header are given in the response, but there is no entity-body in the reply. |
205 Reset Content |
The browser should clear the form used for this transaction for additional input. |
206 Partial Content |
The server is returning partial data of the size requested. Used in response to a request specifying a Range header. The server must specify the range included in the response with the Content-Range header. |
3xx: Redirection
Message: |
Description: |
300 Multiple Choices |
A link list. The user can select a link and go to that location. Maximum five addresses |
301 Moved Permanently |
The requested page has moved to a new url |
302 Found |
The requested page has moved temporarily to a new url |
303 See Other |
The requested page can be found under a different url |
304 Not Modified |
This is the response code to an If-Modified-Since or If-None-Match header, where the URL has not been modified since the specified date. |
305 Use Proxy |
The requested URL must be accessed through the proxy mentioned in the Location header. |
306 Unused |
This code was used in a previous version. It is no longer used, but the code is reserved |
307 Temporary Redirect |
The requested page has moved temporarily to a new url |
4xx: Client Error
Message: |
Description: |
400 Bad Request |
The server did not understand the request |
401 Unauthorized |
The requested page needs a username and a password |
402 Payment Required |
You can not use this code yet |
403 Forbidden |
Access is forbidden to the requested page |
404 Not Found |
The server can not find the requested page |
405 Method Not Allowed |
The method specified in the request is not allowed |
406 Not Acceptable |
The server can only generate a response that is not accepted by the client |
407 Proxy Authentication Required |
You must authenticate with a proxy server before this request can be served |
408 Request Timeout |
The request took longer than the server was prepared to wait |
409 Conflict |
The request could not be completed because of a conflict |
410 Gone |
The requested page is no longer available |
411 Length Required |
The "Content-Length" is not defined. The server will not accept the request without it |
412 Precondition Failed |
The precondition given in the request evaluated to false by the server |
413 Request Entity Too Large |
The server will not accept the request, because the request entity is too large |
414 Request-url Too Long |
The server will not accept the request, because the url is too long. Occurs when you convert a "post" request to a "get" request with a long query information |
415 Unsupported Media Type |
The server will not accept the request, because the media type is not supported |
416 Requested Range Not Satisfiable |
The requested byte range is not available and is out of bounds. |
417 Expectation Failed |
The expectation given in an Expect request-header field could not be met by this server. |
5xx: Server Error
Message: |
Description: |
500 Internal Server Error |
The request was not completed. The server met an unexpected condition |
501 Not Implemented |
The request was not completed. The server did not support the functionality required |
502 Bad Gateway |
The request was not completed. The server received an invalid response from the upstream server |
503 Service Unavailable |
The request was not completed. The server is temporarily overloading or down |
504 Gateway Timeout |
The gateway has timed out |
505 HTTP Version Not Supported |
The server does not support the "http protocol" version |
HTTP - Header Fields
HTTP 标头字段提供有关请求或响应或消息正文中发送的对象的所需信息。有以下四种类型的 HTTP 消息标头:
HTTP deader fields provide required information about the request or response, or about the object sent in the message body. There are following four types of HTTP message headers:
-
General-header: These header fields have general applicability for both request and response messages.
-
Client Request-header: These header fields are applicability only for request messages.
-
Server Response-header: These header fields are applicability only for response messages.
-
Entity-header: These header fields define metainformation about the entity-body or, if no body is present
General Headers
Cache-control
cache-control 通用首部字段用于指定所有缓存系统必须遵循的指令。以下是语法:
The Cache-Control general-header field is used to specify directives that MUST be obeyed by all caching system. Following is the syntax:
Cache-Control : cache-request-directive|cache-response-directive
HTTP 客户端或服务器可以使用 Cache-control 通用首部指定缓存参数或从缓存中请求某些类型的文档。缓存指令在一个逗号分隔的列表中指定。例如:
An HTTP clients or servers can use the Cache-control general header to specify parameters for the cache or to request certain kinds of documents from the cache. The caching directives are specified in a comma-separated list. For example:
Cache-control: no-cache
以下是一些重要的缓存请求指令,客户端可以在 HTTP 请求中使用:
There are following important cache request directives which can be used by the client in its HTTP request:
S.N. |
Cache Request Directive and Description |
1 |
no-cache A cache must not use the response to satisfy a subsequent request without successful revalidation with the origin server. |
2 |
no-store The cache should not store anything about the client request or server response. |
3 |
max-age = seconds Indicates that the client is willing to accept a response whose age is no greater than the specified time in seconds. |
4 |
max-stale [ = seconds ] Indicates that the client is willing to accept a response that has exceeded its expiration time. If seconds are given, it must not be expired by more than that time. |
5 |
min-fresh = seconds Indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the specified time in seconds. |
6 |
no-transform Do not convert the entity-body. |
7 |
only-if-cached Do not retrieve new data. The cache can send a document only if it is in the cache, and should not contact the origin-server to see if a newer copy exists. |
服务器可在其 HTTP 响应中使用以下重要缓存响应指令:
There are following important cache response directives which can be used by the server in its HTTP response:
S.N. |
Cache Request Directive and Description |
1 |
public Indicates that the response may be cached by any cache. |
2 |
private Indicates that all or part of the response message is intended for a single user and must not be cached by a shared cache. |
3 |
no-cache A cache must not use the response to satisfy a subsequent request without successful revalidation with the origin server. |
4 |
no-store The cache should not store anything about the client request or server response. |
5 |
no-transform Do not convert the entity-body. |
6 |
must-revalidate The cache must verify the status of stale documents before using it and expired one should not be used. |
7 |
proxy-revalidate The proxy-revalidate directive has the same meaning as the must- revalidate directive, except that it does not apply to non-shared user agent caches. |
8 |
max-age = seconds Indicates that the client is willing to accept a response whose age is no greater than the specified time in seconds. |
9 |
s-maxage = seconds The maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header. The s-maxage directive is always ignored by a private cache. |
Connection
Connection general-header 域允许发送者指定对该特定连接所需选项,且代理不得通过进一步连接来通信该选项。以下是使用 connection 头的简单语法:
The Connection general-header field allows the sender to specify options that are desired for that particular connection and must not be communicated by proxies over further connections. Following is the simple syntax of using connection header:
Connection : "Connection"
HTTP/1.1 为发送者定义了“closed”连接选项,以表明将在完成响应后关闭该连接。例如:
HTTP/1.1 defines the "closed" connection option for the sender to signal that the connection will be closed after completion of the response. For example:
Connection: Closed
默认情况下,HTTP 1.1使用持久连接,其中连接不会在事务后自动关闭。另一方面,HTTP 1.0默认情况下没有持久连接。如果1.0客户端希望使用持久连接,它将使用`@ {s1}`参数,如下所示:
By default, HTTP 1.1 uses persistent connections, where the connection does not automatically close after a transaction. HTTP 1.0, on the other hand, does not have persistent connections by default. If a 1.0 client wishes to use persistent connections, it uses the keep-alive parameter as follows:
Connection: keep-alive
Date
所有HTTP日期/时间戳都必须以格林尼治标准时间(GMT)表示,无一例外。HTTP应用程序可以使用以下三种日期/时间戳表示形式中的任何一种:
All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception. HTTP applications are allowed to use any of the following three representations of date/time stamps:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
此处第一种格式是最优选的格式。
Here first format is the most preferred one.
Pragma
Pragma general-header 域用于包括可能适用于请求/响应链中任何接收者的实现特定指令。例如:
The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. For example:
Pragma: no-cache
HTTP/1.0 中定义的唯一指令为 no-cache 指令,且为了向后兼容而维持在 HTTP 1.1 中。将来不会再定义新的 Pragma 指令。
The only directive defined in HTTP/1.0 is the no-cache directive and is maintained in HTTP 1.1 for backward compatibility. No new Pragma directives will be defined in the future.
Trailer
Trailer general 域值表明给定头域集存在于使用分块传输编码编码的消息预告中。以下是 Trailer 头域的语法:
The Trailer general field value indicates that the given set of header fields is present in the trailer of a message encoded with chunked transfer-coding. Following is the syntax of Trailer header field:
Trailer : field-name
Trailer 头域中列出的消息头域不得包含以下头域:
Message header fields listed in the Trailer header field must not include the following header fields:
-
Transfer-Encoding
-
Content-Length
-
Trailer
Transfer-Encoding
Transfer-Encoding general-header 域表示已经针对消息体应用哪种类型的转换,以为便于在发送者和接收者之间安全传输该消息。这与 content-encoding 不同,因为传输编码是消息的属性,而不是实体体的属性。以下是 Transfer-Encoding 头域的语法:
The Transfer-Encoding general-header field indicates what type of transformation has been applied to the message body in order to safely transfer it between the sender and the recipient. This is not the same as content-encoding because transfer-encodings are a property of the message, not of the entity-body. Following is the syntax of Transfer-Encoding header field:
Transfer-Encoding: chunked
所有传输编码值不区分大小写。
All transfer-coding values are case-insensitive.
Upgrade
Upgrade 通用标题允许客户端指定其支持的其他通信协议,如果服务器发现切换协议合适,则客户端希望使用这些协议。例如:
The Upgrade general-header allows the client to specify what additional communication protocols it supports and would like to use if the server finds it appropriate to switch protocols. For example:
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
Upgrade 头域旨在为从 HTTP/1.1 转换到其他不兼容协议提供一个简单的机制
The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible protocol
Via
网关和代理必须使用 Via 通用头字段来指示中间协议和接收者。例如,请求消息可以从 HTTP/1.0 用户代理发送到内部代理(代号为“fred”),该代理使用 HTTP/1.1 将请求转发到 nowhere.com 上的公共代理,该代理通过将请求转发到 www.ics.uci.edu 上的原始服务器来完成请求。然后,www.ics.uci.edu 收到的请求将具有以下 Via 头字段:
The Via general-header must be used by gateways and proxies to indicate the intermediate protocols and recipients. For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses HTTP/1.1 to forward the request to a public proxy at nowhere.com, which completes the request by forwarding it to the origin server at www.ics.uci.edu. The request received by www.ics.uci.edu would then have the following Via header field:
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Upgrade 头域旨在为从 HTTP/1.1 转换到其他不兼容协议提供一个简单的机制
The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible protocol
Warning
Warning 通用标题用于携带有关消息状态或转换的其他信息,这些信息可能不会反映在消息中。响应可能携带多个 Warning 标题。
The Warning general-header is used to carry additional information about the status or transformation of a message which might not be reflected in the message. A response may carry more than one Warning header.
Warning : warn-code SP warn-agent SP warn-text SP warn-date
Client Request Headers
Accept
Accept request-header 域可用于指定对响应而言可接受的特定媒体类型。以下是通用语法:
The Accept request-header field can be used to specify certain media types which are acceptable for the response. Following is the general syntax:
Accept: type/subtype [q=qvalue]
可以列出用逗号分隔的多个媒体类型,并且可选的 qvalue 表示在 0 到 1 的范围内接受类型的可接受质量级别。以下是一个示例:
Multiple media types can be listed separated by commas and the optional qvalue represents an acceptable quality level for accept types on a scale of 0 to 1. Following is an example:
Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c
这将被解释为 text/html 和 text/x-c 为首选媒体类型,但如果它们不存在,则发送 text/x-dvi 实体,如果该实体不存在,则发送 text/plain 实体。
This would be interpreted as text/html and text/x-c are the preferred media types, but if they do not exist, then send the text/x-dvi entity, and if that does not exist, send the text/plain entity.
Accept-Charset
Accept-Charset 请求头字段可用于指示响应可以接受哪些字符集。以下是基本语法:
The Accept-Charset request-header field can be used to indicate what character sets are acceptable for the response. Following is the general syntax:
Accept-Charset: character_set [q=qvalue]
多个字符集可以通过逗号分隔列出,可选的 qvalue 表示非首选字符集的可接受质量级别(范围 0 到 1)。以下是一个示例:
Multiple character sets can be listed separated by commas and the optional qvalue represents an acceptable quality level for nonpreferred character sets on a scale of 0 to 1. Following is an example:
Accept-Charset: iso-8859-5, unicode-1-1; q=0.8
特殊值 " ", if present in the *Accept-Charset 字段与所有字符集匹配,并且如果不存在 Accept-Charset 头,则默认为可接受任何字符集。
The special value "", if present in the *Accept-Charset field, matches every character set and if no Accept-Charset header is present, the default is that any character set is acceptable.
Accept-Encoding
Accept-Encoding 请求头字段类似于 Accept,但限制了响应中可接受的内容编码。以下是基本语法:
The Accept-Encoding request-header field is similar to Accept, but restricts the content-codings that are acceptable in the response. Following is the general syntax:
Accept-Encoding: encoding types
以下是一些示例:
Following are examples:
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
Accept-Language
Accept-Language 请求头字段类似于 Accept,但限制了作为响应请求的首选自然语言集。以下是基本语法:
The Accept-Language request-header field is similar to Accept, but restricts the set of natural languages that are preferred as a response to the request. Following is the general syntax:
Accept-Language: language [q=qvalue]
多个语言可以通过逗号分隔列出,可选的 qvalue 表示非首选语言的可接受质量级别(范围 0 到 1)。以下是一个示例:
Multiple languages can be listed separated by commas and the optional qvalue represents an acceptable quality level for nonpreferred languages on a scale of 0 to 1. Following is an example:
Accept-Language: da, en-gb;q=0.8, en;q=0.7
Authorization
Authorization 请求头字段的值由凭据组成,其中包含用户代理对请求的资源域进行身份验证的信息。以下是基本语法:
The Authorization request-header field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. Following is the general syntax:
Authorization : credentials
HTTP/1.0 规范定义了 BASIC 授权方案,其中授权参数为 username:password ,用 base64 编码。以下是一个示例:
The HTTP/1.0 specification defines the BASIC authorization scheme, where the authorization parameter is the string of username:password encoded in base 64. Following is an example:
Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=
该值解码为 guest:guest123 ,其中 guest 是用户 ID, guest123 是密码。
The value decodes into is guest:guest123 where guest is user ID and guest123 is the password.
Cookie
Cookie 请求头字段的值包含存储用于该 URL 的信息的名/值对。以下是基本语法:
The Cookie request-header field value contains a name/value pair of information stored for that URL. Following is the general syntax:
Cookie: name=value
多个 Cookie 可以用分号分隔来指定,如下所示:
Multiple cookies can be specified separated by semicolons as follows:
Cookie: name1=value1;name2=value2;name3=value3
Expect
Expect 请求头字段用于指示客户端需要特定服务器行为。以下是基本语法:
The Expect request-header field is used to indicate that particular server behaviors are required by the client. Following is the general syntax:
Expect : 100-continue | expectation-extension
如果服务器收到包含 Expect 字段的请求,该字段包含其不支持的期望扩展,则它必须以 417(期望失败)状态进行响应。
If a server receives a request containing an Expect field that includes an expectation-extension that it does not support, it must respond with a 417 (Expectation Failed) status.
From
From 请求头字段包含控制请求用户代理的人员的互联网电子邮件地址。以下是一个简单的示例:
The From request-header field contains an Internet e-mail address for the human user who controls the requesting user agent. Following is a simple example:
From: webmaster@w3.org
此头字段可用于记录目的以及作为识别无效或不需要的请求的源的工具。
This header field may be used for logging purposes and as a means for identifying the source of invalid or unwanted requests.
Host
Host 请求头字段用于指定所请求资源的互联网主机和端口号。以下是基本语法:
The Host request-header field is used to specify the Internet host and port number of the resource being requested. Following is the general syntax:
Host : "Host" ":" host [ ":" port ] ;
不带任何尾随端口信息的 host 表示默认端口 80。例如,[role="bare"] [role="bare"]http://www.w3.org/pub/WWW/ 上对来源服务器的请求将为:
A host without any trailing port information implies the default port, which is 80. For example, a request on the origin server for [role="bare"]http://www.w3.org/pub/WWW/ would be:
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
If-Match
If-Match 请求头字段与方法一起使用,以使其有条件。此头请求服务器仅在给定标签中的值与 ETag 表示的给定实体标签匹配时才执行所请求的方法。以下是基本语法:
The If-Match request-header field is used with a method to make it conditional. This header request the server to perform the requested method only if given value in this tag matches the given entity tags represented by ETag. Following is the general syntax:
If-Match : entity-tag
星号 (*) 匹配任何实体,且仅当实体存在时事务才会继续。以下是一些可能的示例:
An asterisk (*) matches any entity, and the transaction continues only if the entity exists. Following are possible examples:
If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *
如果没有任何实体标记匹配,或者给出了 "*" 且没有任何当前实体存在,则服务器不得执行请求的方法,并且必须返回 412(前提条件失败)响应。
If none of the entity tags match, or if "*" is given and no current entity exists, the server must not perform the requested method, and must return a 412 (Precondition Failed) response.
If-Modified-Since
If-Modified-Since 请求头字段与方法一起使用以使其成为条件请求。如果请求的 URL 自该字段中指定的时间以来未被修改,则不会从服务器返回实体;相反将返回一个没有消息正文的 304(未修改)响应。以下是通用语法:
The If-Modified-Since request-header field is used with a method to make it conditional. If the requested URL has not been modified since the time specified in this field, an entity will not be returned from the server; instead, a 304 (not modified) response will be returned without any message-body. Following is the general syntax:
If-Modified-Since : HTTP-date
该字段的一个示例是:
An example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
如果没有任何实体标记匹配,或者给出了 "*" 且没有任何当前实体存在,则服务器不得执行请求的方法,并且必须返回 412(前提条件失败)响应。
If none of the entity tags match, or if "*" is given and no current entity exists, the server must not perform the requested method, and must return a 412 (Precondition Failed) response.
If-None-Match
If-None-Match 请求头字段与方法一起使用以使其成为条件请求。此标头只有当此标记中给定的值之一与 ETag 表示的给定实体标记匹配时才请求服务器执行请求的方法。以下是通用语法:
The If-None-Match request-header field is used with a method to make it conditional. This header request the server to perform the requested method only if one of the given value in this tag matches the given entity tags represented by ETag. Following is the general syntax:
If-None-Match : entity-tag
星号 (*) 匹配任何实体,并且仅当实体不存在时事务才会继续。以下是一些可能的示例:
An asterisk (*) matches any entity, and the transaction continues only if the entity does not exist. Following are possible examples:
If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *
If-Range
If-Range 请求头字段可以与条件 GET 一起使用,以仅请求丢失的实体部分(如果它没有被更改),而如果实体已被更改,则请求实体的全部内容。以下是通用语法:
The If-Range request-header field can be used with a conditional GET to request only the portion of the entity that is missing, if it has not been changed, and the entire entity if it has changed. Following is the general syntax:
If-Range : entity-tag | HTTP-date
可以实体标记或日期来标识已收到的部分实体。例如:
Either an entity tag or a date can be used to identify the partial entity already received. For example:
If-Range: Sat, 29 Oct 1994 19:43:31 GMT
在此,如果自给定日期以来文档未被修改,则服务器将返回由 Range 标头给出的字节范围,否则返回所有新文档。
Here if the document has not been modified since the given date, the server returns the byte range given by the Range header otherwise, it returns all of the new document.
If-Unmodified-Since
If-Unmodified-Since 请求头字段与方法一起使用以使其成为条件请求。以下是通用语法:
The If-Unmodified-Since request-header field is used with a method to make it conditional. Following is the general syntax:
If-Unmodified-Since : HTTP-date
如果请求的资源自该字段中指定的时间以来未被修改,则服务器应像 If-Unmodified-Since 标头不存在那样执行请求的操作。例如:
If the requested resource has not been modified since the time specified in this field, the server should perform the requested operation as if the If-Unmodified-Since header were not present. For example:
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
如果请求通常会导致除 2xx 或 412 状态之外的其他任何状态,则应忽略 If-Unmodified-Since 标头。
If the request normally would result in anything other than a 2xx or 412 status, the If-Unmodified-Since header should be ignored.
Max-Forwards
Max-Forwards 请求头字段为 TRACE 和 OPTIONS 方法提供了一种机制,以限制可以将请求转发到下一个入站服务器的代理或网关的数量。以下是通用语法:
The Max-Forwards request-header field provides a mechanism with the TRACE and OPTIONS methods to limit the number of proxies or gateways that can forward the request to the next inbound server. Following is the general syntax:
Max-Forwards : n
Max-Forwards 值是一个十进制整数,表示此请求消息可以被转发的剩余次数。这对于用 TRACE 方法进行调试非常有用,可以避免无限循环。例如:
The Max-Forwards value is a decimal integer indicating the remaining number of times this request message may be forwarded. This is useful for debugging with the TRACE method, avoiding infinite loops. For example:
Max-Forwards : 5
对于 HTTP 规范中定义的所有其他方法,可以忽略 Max-Forwards 标头字段。
The Max-Forwards header field may be ignored for all other methods defined in HTTP specification.
Proxy-Authorization
Proxy-Authorization 请求头字段允许客户端向要求身份验证的代理识别自身(或其用户)。以下是通用语法:
The Proxy-Authorization request-header field allows the client to identify itself (or its user) to a proxy which requires authentication. Following is the general syntax:
Proxy-Authorization : credentials
Proxy-Authorization 字段值包含凭据,其中包含用户代理针对被请求资源的代理和/或域的认证信息。
The Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested.
Range
Range 请求头字段指定从文档中请求的内容的部分范围。以下是通用语法:
The Range request-header field specifies the partial range(s) of the content requested from the document. Following is the general syntax:
Range: bytes-unit=first-byte-pos "-" [last-byte-pos]
字节范围规范中的 first-byte-pos 值给出范围中第一个字节的字节偏移量。last-byte-pos 值给出范围中最后一个字节的字节偏移量;也就是说,指定的字节位置是包含的。您可以将字节单位指定为字节 字节偏移量从零开始。以下是一些简单的示例:
The first-byte-pos value in a byte-range-spec gives the byte-offset of the first byte in a range. The last-byte-pos value gives the byte-offset of the last byte in the range; that is, the byte positions specified are inclusive. You can specify a byte-unit as bytes Byte offsets start at zero. Following are a simple examples:
- The first 500 bytes
Range: bytes=0-499
- The second 500 bytes
Range: bytes=500-999
- The final 500 bytes
Range: bytes=-500
- The first and last bytes only
Range: bytes=0-0,-1
多个范围可以使用逗号分隔来列出。如果逗号分隔的字节范围内的第一个数字丢失,则该范围从文档结尾开始计。如果第二个数字丢失,则该范围从字节 n 开始到文档的结尾。
Multiple ranges can be listed, separated by commas. If the first digit in the comma-separated byte range(s) is missing, the range is assumed to count from the end of the document. If the second digit is missing, the range is byte n to the end of the document.
Referer
Referer 请求头字段允许客户端指定已从其中请求 URL 的资源的地址 (URI)。以下是一般语法:
The Referer request-header field allows the client to specify the address (URI) of the resource from which the URL has been requested. Following is the general syntax:
Referer : absoluteURI | relativeURI
以下是一个简单的示例:
Following is a simple example:
Referer: http://www.tutorialspoint.org/http/index.htm
如果字段值是相对 URI,则应相对于 Request-URI 进行解释。
If the field value is a relative URI, it should be interpreted relative to the Request-URI.
TE
TE 请求头字段表明其可能在哪种扩展传输编码中接受响应,以及是否可能接受块传输编码中的拖尾字段。以下是一般语法:
The TE request-header field indicates what extension transfer-coding it is willing to accept in the response and whether or not it is willing to accept trailer fields in a chunked transfer-coding. Following is the general syntax:
TE : t-codings
关键字“trailers”的存在表明该客户端愿意在块传输编码中接受拖尾字段,并且可以指定为以下两种方式之一:
The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding and it is specified either of the ways:
TE: deflate
TE:
TE: trailers, deflate;q=0.5
如果 TE 字段值为空或没有 TE 字段,则唯一的传输编码是块传输编码。没有传输编码的消息始终是可接受的。
If the TE field-value is empty or if no TE field is present, the only transfer-coding is chunked. A message with no transfer-coding is always acceptable.
Server Response Headers
Accept-Ranges
Accept-Ranges 响应头字段允许服务器指示其接受对某个资源的范围请求。以下是一般语法:
The Accept-Ranges response-header field allows the server to indicate its acceptance of range requests for a resource. Following is the general syntax:
Accept-Ranges : range-unit | none
例如,可以接受字节范围请求的服务器可能会发送
For example a server that accept byte-range requests may send
Accept-Ranges: bytes
不接受任何类型的对某个资源的范围请求的服务器可能发送:
Servers that do not accept any kind of range request for a resource may send:
Accept-Ranges: none
这将建议客户端不要尝试范围请求。
This will advise the client not to attempt a range request.
Age
Age 响应头字段传达发送者估算的响应(或其重新验证)在原始服务器生成后的时间量。以下是一般语法:
The Age response-header field conveys the sender’s estimate of the amount of time since the response (or its revalidation) was generated at the origin server. Following is the general syntax:
Age : delta-seconds
Age 值是非负十进制整数,代表以秒为单位的时间。以下是一个简单的示例:
Age values are non-negative decimal integers, representing time in seconds. Following is a simple example:
Age: 1030
包含缓存的 HTTP/1.1 服务器必须在从其自身缓存生成的每个响应中包含一个 Age 头字段。
An HTTP/1.1 server that includes a cache must include an Age header field in every response generated from its own cache.
ETag
ETag 响应头字段提供所请求变体的实体标记的当前值。以下是通用语法:
The ETag response-header field provides the current value of the entity tag for the requested variant. Following is the general syntax:
ETag : entity-tag
以下是简单的示例:
Following are simple examples:
ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""
Location
Location 响应头字段用于将接收者重定向到 Request-URI 以外的位置进行完成。以下是一般语法:
The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion. Following is the general syntax:
Location : absoluteURI
以下是一个简单的示例:
Following is a simple example:
Location: http://www.tutorialspoint.org/http/index.htm
Content-Location 头字段与 Location 不同,因为 Content-Location 标识请求中包含的实体的原始位置。
The Content-Location header field differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request.
Proxy-Authenticate
代理认证响应头字段必须作为 407(代理认证需要)响应的一部分包含在内。以下是通用语法:
The Proxy-Authenticate response-header field must be included as part of a 407 (Proxy Authentication Required) response. Following is the general syntax:
Proxy-Authenticate : challenge
Retry-After
重试后响应头字段可与 503(服务不可用)响应搭配使用,以指示服务预计对请求客户端不可用的时间。以下是通用语法:
The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. Following is the general syntax:
Retry-After : HTTP-date | delta-seconds
以下是两个简单的示例:
Following are two simple examples:
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
在后一个示例中,延迟为 2 分钟。
In the latter example, the delay is 2 minutes.
Server
服务器响应头字段包含有关原始服务器用来处理请求的软件的信息。以下是通用语法:
The Server response-header field contains information about the software used by the origin server to handle the request. Following is the general syntax:
Server : product | comment
以下是一个简单的示例:
Following is a simple example:
Server: Apache/2.2.14 (Win32)
如果响应通过代理转发,代理应用程序不得修改服务器响应头。
If the response is being forwarded through a proxy, the proxy application must not modify the Server response-header.
Set-Cookie
设置 Cookie 响应头字段包含一个用于保留此 URL 的名称/值对。以下是通用语法:
The Set-Cookie response-header field contains a name/value pair of information to retain for this URL. Following is the general syntax:
Set-Cookie: NAME=VALUE; OPTIONS
设置 Cookie 响应头包含令牌 Set-Cookie:,后跟一个一个或多个 Cookie 的逗号分隔列表。以下是您可以指定为选项的可能值:
Set-Cookie response header comprises the token Set-Cookie:, followed by a comma-separated list of one or more cookies. Here are possible values you can specify as options:
S.N. |
Options and Description |
1 |
Comment=comment This option can be used to specify any comment associated with the cookie. |
2 |
* Domain=domain* The Domain attribute specifies the domain for which the cookie is valid. |
3 |
Expires=Date-time The date the cookie will expire. If this is blank, the cookie will expire when the visitor quits the browser |
4 |
* Path=path* The Path attribute specifies the subset of URLs to which this cookie applies. |
5 |
Secure This instructs the user agent to return the cookie only under a secure connection. |
以下是服务器生成的一个简单 Cookie 头的示例:
Following is an example of a simple cookie header generated by the server:
Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT
Vary
Vary 响应头字段指定实体有多个来源,因此可能会根据指定的请求头列表而异。以下是通用语法:
The Vary response-header field specifies that the entity has multiple sources and may therefore vary according to specified list of request header(s). Following is the general syntax:
Vary : field-name
您可以在逗号分隔符后指定多个头,而星号“*”的值表示不限于请求头的未指定参数。以下是一个简单的示例:
You can specify multiple headers separated by commas and a value of asterisk "*" signals that unspecified parameters not limited to the request-headers. Following is a simple example:
Vary: Accept-Language, Accept-Encoding
此处字段名不区分大小写。
Here field names are case-insensitive.
WWW-Authenticate
WWW-Authenticate 响应头字段必须包含在 401(未授权)响应消息中。该字段值由至少一个挑战组成,该挑战指示适用于 Request-URI 的认证方案和参数。以下是通用语法:
The WWW-Authenticate response-header field must be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. Following is the general syntax:
WWW-Authenticate : challenge
WWW-Authenticate 字段值因为它可能包含多个挑战,或者提供了多个 WWW-Authenticate 头字段,所以挑战本身的内容可以包含一个认证参数逗号分隔列表。以下是一个简单的示例:
WWW- Authenticate field value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters. Following is a simple example:
WWW-Authenticate: BASIC realm="Admin"
Entity Headers
Allow
Allow 实体首字段列出了由请求 URI 标识的资源支持的方法集。以下是其通用语法:
The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI. Following is the general syntax:
Allow : Method
你可以指定以逗号分隔的多方法。以下是一个简单的示例:
You can specify multiple method separated by commas. Following is a simple example:
Allow: GET, HEAD, PUT
此字段不能防止客户端尝试其他方法。
This field cannot prevent a client from trying other methods.
Content-Encoding
Content-Encoding 实体首字段用作媒体类型的修饰符。以下是其通用语法:
The Content-Encoding entity-header field is used as a modifier to the media-type. Following is the general syntax:
Content-Encoding : content-coding
内容编码是请求 URI 标识的实体的一个特征。以下是一个简单的示例:
The content-coding is a characteristic of the entity identified by the Request-URI. Following is a simple example:
Content-Encoding: gzip
如果请求消息中实体的内容编码对原始服务器不可接受,则服务器应以 415(不支持的媒体类型)状态代码进行响应。
If the content-coding of an entity in a request message is not acceptable to the origin server, the server should respond with a status code of 415 (Unsupported Media Type).
Content-Language
Content-Language 实体首字段描述了所附实体的预期受众的自然语言。以下是其通用语法:
The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. Following is the general syntax:
Content-Language : language-tag
针对多个受众的内容可能会列出多种语言。以下是一个简单的示例:
Multiple languages may be listed for content that is intended for multiple audiences. Following is a simple example:
Content-Language: mi, en
Content-Language 的主要目的是允许用户根据自己的首选语言识别和区分实体。
The primary purpose of Content-Language is to allow a user to identify and differentiate entities according to the user’s own preferred language.
Content-Length
Content-Length 实体首字段指明发送给收件人的实体主体的大小,以十进制的八位字节数表示,或者对于 HEAD 方法而言,指明如果请求是 GET 发送的实体主体的大小。以下是其通用语法:
The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. Following is the general syntax:
Content-Length : DIGITS
以下是一个简单的示例:
Following is a simple example:
Content-Length: 3495
任何大于或等于零的内容长度都是一个有效值。
Any Content-Length greater than or equal to zero is a valid value.
Content-Location
Content-Location 实体头字段可用于在实体可从请求资源的 URI 处不同的某个位置访问时,提供该消息中封送实体的资源位置。后面给出一般语法:
The Content-Location entity-header field may be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource’s URI. Following is the general syntax:
Content-Location: absoluteURI | relativeURI
以下是一个简单的示例:
Following is a simple example:
Content-Location: http://www.tutorialspoint.org/http/index.htm
Content-Location 的值也定义了该实体的基 URI。
The value of Content-Location also defines the base URI for the entity.
Content-MD5
Content-MD5 实体头字段可用于在收到时提供实体的 MD5 摘要,以检查消息的完整性。后面给出一般语法:
The Content-MD5 entity-header field may be used to supply an MD5 digest of the entity, for checking the integrity of the message upon receipt. Following is the general syntax:
Content-MD5 : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864
以下是一个简单的示例:
Following is a simple example:
Content-MD5 : 8c2d46911f3f5a326455f0ed7a8ed3b3
MD5 摘要基于实体体的内容(包括已应用的所有内容编码)计算得出,但不包括对消息体应用的传输编码。
The MD5 digest is computed based on the content of the entity-body, including any content-coding that has been applied, but not including any transfer-encoding applied to the message-body.
Content-Range
Content-Range 实体头字段随部分实体体一同发送,指定在完整实体体中应将部分体应用于何处。后面给出一般语法:
The Content-Range entity-header field is sent with a partial entity-body to specify where in the full entity-body the partial body should be applied. Following is the general syntax:
Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos
假设该实体总共包含 1234 个字节,下面给出 byte-content-range-spec 值的示例:
Examples of byte-content-range-spec values, assuming that the entity contains a total of 1234 bytes:
- The first 500 bytes:
Content-Range : bytes 0-499/1234
- The second 500 bytes:
Content-Range : bytes 500-999/1234
- All except for the first 500 bytes:
Content-Range : bytes 500-1233/1234
- The last 500 bytes:
Content-Range : bytes 734-1233/1234
当一条 HTTP 消息包括一个单一范围的内容时,此内容会随 Content-Range 头一同传输,且 Content-Length 头显示实际传输的字节数。例如,
When an HTTP message includes the content of a single range, this content is transmitted with a Content-Range header, and a Content-Length header showing the number of bytes actually transferred. For example,
HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
Content-Type
Content-Type 实体头字段指示发送给接收方的实体体的媒体类型,或者在 HEAD 方法的情况下,表示在该请求是 GET 的情况下将发送的媒体类型。后面给出一般语法:
The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET. Following is the general syntax:
Content-Type : media-type
下面是一个示例:
Following is an example:
Content-Type: text/html; charset=ISO-8859-4
Expires
Expires 实体头字段提供反应被认为过时的日期/时间。后面给出一般语法:
The Expires entity-header field gives the date/time after which the response is considered stale. Following is the general syntax:
Expires : HTTP-date
下面是一个示例:
Following is an example:
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Last-Modified
Last-Modified 实体头字段指示源服务器认为该变量上次被修改的日期和时间。后面给出一般语法:
The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified. Following is the general syntax:
Last-Modified: HTTP-date
下面是一个示例:
Following is an example:
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
HTTP - Caching
HTTP 通常用于分布式信息系统,其中可以通过使用响应缓存提高性能。HTTP/1.1 协议包含用于执行缓存工作的若干元素。
HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. The HTTP/1.1 protocol includes a number of elements intended to make caching work.
HTTP/1.1 中缓存的目标是消除在许多情况下发送请求的需求,并消除在许多其他情况下发送完整响应的需求。
The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases.
HTTP/1.1 中基本的缓存机制是向缓存发出的隐式指令,其中服务器指定了过期时间和验证器。为此我们使用 Cache-Control 头。
The basic cache mechanisms in HTTP/1.1 are implicit directives to caches where server-specifies expiration times and validators. We use the Cache-Control header for this purpose.
Cache-Control 头允许客户端或服务器在请求或响应中传输各种指令。这些指令通常会覆盖默认缓存算法。缓存指令在一个逗号分隔列表中指定。例如:
The Cache-Control header allows a client or server to transmit a variety of directives in either requests or responses. These directives typically override the default caching algorithms. The caching directives are specified in a comma-separated list. For example:
Cache-control: no-cache
以下是一些重要的缓存请求指令,客户端可以在 HTTP 请求中使用:
There are following important cache request directives which can be used by the client in its HTTP request:
S.N. |
Cache Request Directive and Description |
1 |
no-cache A cache must not use the response to satisfy a subsequent request without successful revalidation with the origin server. |
2 |
no-store The cache should not store anything about the client request or server response. |
3 |
max-age = seconds Indicates that the client is willing to accept a response whose age is no greater than the specified time in seconds. |
4 |
max-stale [ = seconds ] Indicates that the client is willing to accept a response that has exceeded its expiration time. If seconds are given, it must not be expired by more than that time. |
5 |
min-fresh = seconds Indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the specified time in seconds. |
6 |
no-transform Do not convert the entity-body. |
7 |
only-if-cached Do not retrieve new data. The cache can send a document only if it is in the cache, and should not contact the origin-server to see if a newer copy exists. |
服务器可在其 HTTP 响应中使用以下重要缓存响应指令:
There are following important cache response directives which can be used by the server in its HTTP response:
S.N. |
Cache Response Directive and Description |
1 |
public Indicates that the response may be cached by any cache. |
2 |
private Indicates that all or part of the response message is intended for a single user and must not be cached by a shared cache. |
3 |
no-cache A cache must not use the response to satisfy a subsequent request without successful revalidation with the origin server. |
4 |
no-store The cache should not store anything about the client request or server response. |
5 |
no-transform Do not convert the entity-body. |
6 |
must-revalidate The cache must verify the status of stale documents before using it and expired one should not be used. |
7 |
proxy-revalidate The proxy-revalidate directive has the same meaning as the must- revalidate directive, except that it does not apply to non-shared user agent caches. |
8 |
max-age = seconds Indicates that the client is willing to accept a response whose age is no greater than the specified time in seconds. |
9 |
s-maxage = seconds The maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header. The s-maxage directive is always ignored by a private cache. |
HTTP - URL Encoding
HTTP URL 只能使用 ASCII 字符集通过互联网发送,其中通常包含 ASCII 字符集之外的字符。因此,这些不安全的字符必须替换为 % 后接两个十六进制数字。
HTTP URLs can only be sent over the Internet using the ASCII character-set, which often contain characters outside the ASCII set. So these unsafe characters must be replaced with a % followed by two hexadecimal digits.
下表显示了字符的 ASCII 符号及其相等的符号,最后是可用于在将 URL 传递给服务器之前在 URL 中使用的替换:
Following table shows ASCII symbol of the character and its equal Symbol and finally its replacement which can be used in URL before passing it to the server:
ASCII |
Symbol |
Replacement |
< 32 |
Encode with %xx where xx is the hexadecimal representation of the character. |
|
32 |
space |
+ or %20 |
33 |
! |
%21 |
34 |
" |
%22 |
35 |
# |
%23 |
36 |
$ |
%24 |
37 |
% |
%25 |
38 |
& |
%26 |
39 |
' |
%27 |
40 |
( |
%28 |
41 |
) |
%29 |
42 |
* |
* |
43 |
+ |
%2B |
44 |
, |
%2C |
45 |
- |
- |
46 |
. |
. |
47 |
/ |
%2F |
48 |
0 |
0 |
49 |
1 |
1 |
50 |
2 |
2 |
51 |
3 |
3 |
52 |
4 |
4 |
53 |
5 |
5 |
54 |
6 |
6 |
55 |
7 |
7 |
56 |
8 |
8 |
57 |
9 |
9 |
58 |
: |
%3A |
59 |
; |
%3B |
60 |
< |
%3C |
61 |
= |
%3D |
62 |
> |
%3E |
63 |
? |
%3F |
64 |
@ |
%40 |
65 |
A |
A |
66 |
B |
B |
67 |
C |
C |
68 |
D |
D |
69 |
E |
E |
70 |
F |
F |
71 |
G |
G |
72 |
H |
H |
73 |
I |
I |
74 |
J |
J |
75 |
K |
K |
76 |
L |
L |
77 |
M |
M |
78 |
N |
N |
79 |
O |
O |
80 |
P |
P |
81 |
Q |
Q |
82 |
R |
R |
83 |
S |
S |
84 |
T |
T |
85 |
U |
U |
86 |
V |
V |
87 |
W |
W |
88 |
X |
X |
89 |
Y |
Y |
90 |
Z |
Z |
91 |
[ |
%5B |
92 |
%5C |
|
93 |
] |
%5D |
94 |
^ |
%5E |
95 |
_ |
_ |
96 |
` |
%60 |
97 |
a |
a |
98 |
b |
b |
99 |
c |
c |
100 |
d |
d |
101 |
e |
e |
102 |
f |
f |
103 |
g |
g |
104 |
h |
h |
105 |
i |
i |
106 |
j |
j |
107 |
k |
k |
108 |
l |
l |
109 |
m |
m |
110 |
n |
n |
111 |
o |
o |
112 |
p |
p |
113 |
q |
q |
114 |
r |
r |
115 |
s |
s |
116 |
t |
t |
117 |
u |
u |
118 |
v |
v |
119 |
w |
w |
120 |
x |
x |
121 |
y |
y |
122 |
z |
z |
123 |
{ |
%7B |
124 |
||
%7C |
125 |
} |
%7D |
126 |
~ |
%7E |
127 |
|
%7F |
> 127 |
HTTP - Security
HTTP用于互联网通信,因此应用程序开发人员、信息提供商和用户应当了解HTTP/1.1中的安全限制。本讨论不包括本文中所提问题的明确解决方案,但会提出一些减少安全风险的建议。
HTTP is used for a communication over the internet, so application developers, information providers, and users should be aware of the security limitations in HTTP/1.1. This discussion does not include definitive solutions to the problems mentioned here but it does make some suggestions for reducing security risks.
Personal Information leakage
HTTP客户端通常能够访问大量的个人信息,例如用户名、位置、邮件地址、密码、加密密钥等。因此,应十分小心,防止此类信息通过HTTP协议泄露给其他来源。
HTTP clients are often privy to large amounts of personal information such as the user’s name, location, mail address, passwords, encryption keys, etc. So you should be very careful to prevent unintentional leakage of this information via the HTTP protocol to other sources.
-
All the confidential information should be stored at server side in encrypted form.
-
Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes.
-
Proxies which serve as a portal through a network firewall should take special precautions regarding the transfer of header information that identifies the hosts behind the firewall.
-
The information sent in the From field might conflict with the user’s privacy interests or their site’s security policy, and hence it should not be transmitted without the user being able to disable, enable, and modify the contents of the field.
-
Clients should not include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
-
Authors of services which use the HTTP protocol should not use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI
File and path names based attack
文档应限于HTTP请求返回的文档,仅限服务器管理员预期的那些文档。
The document should be restricted to the documents returned by HTTP requests to be only those that were intended by the server administrators.
例如,UNIX、Microsoft Windows和其他操作系统使用 .. 作为路径组件,以指示高于当前目录的目录级别。在这样的系统上,如果请求URI中包含这样的结构,且该结构将允许访问预期通过HTTP服务器访问的资源之外的资源,则HTTP服务器必须禁止在请求URI中包含这样的结构。
For example, UNIX, Microsoft Windows, and other operating systems use .. as a path component to indicate a directory level above the current one. On such a system, an HTTP server MUST disallow any such construct in the Request-URI if it would otherwise allow access to a resource outside those intended to be accessible via the HTTP server.
DNS Spoofing
使用HTTP的客户端严重依赖域名服务,因此通常容易受到基于IP地址和DNS名称故意错误关联的安全攻击。因此,客户端在假设IP编号/DNS名称关联的持续有效性时需要谨慎小心。
Clients using HTTP rely heavily on the Domain Name Service, and are thus generally prone to security attacks based on the deliberate mis-association of IP addresses and DNS names. So clients need to be cautious in assuming the continuing validity of an IP number/DNS name association.
如果HTTP客户端缓存主机名查找结果以提高性能,则它们必须遵守DNS报告的TTL信息。如果HTTP客户端不遵守此规则,则在以前访问的服务器的IP地址发生更改时,它们可能会受到欺骗。
If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they must observe the TTL information reported by DNS. If HTTP clients do not observe this rule, they could be spoofed when a previously-accessed server’s IP address changes.
Location Headers and Spoofing
如果单一服务器支持多个彼此不信任的组织,那么它必须检查响应中生成在这些组织控制之下的Location和Content- Location标头值,以确保它们不会尝试使它们无权管理的资源无效。
If a single server supports multiple organizations that do not trust one another, then it MUST check the values of Location and Content- Location headers in responses that are generated under control of said organizations to make sure that they do not attempt to invalidate resources over which they have no authority.
Authentication Credentials
现有的HTTP客户端和用户代理通常无限期地保留认证信息。HTTP/1.1.不为服务器提供方法,指示客户端丢弃这些缓存的凭据,这是一个很大的安全风险。
Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP/1.1. does not provide a method for a server to direct clients to discard these cached credentials which is a big security risk.
本问题的部分内容有许多变通方法,因此建议在屏幕保护程序、闲置超时和其他方法(缓解此问题固有安全问题)中使用密码保护。
There are a number of work- arounds to parts of this problem, and so its is recommended to make the use of password protection in screen savers, idle time-outs, and other methods which mitigate the security problems inherent in this problem.
Proxies and Caching
HTTP代理是中间人,代表着中间人攻击机会。代理可以访问与安全性相关的信息、关于个人用户和组织的个人信息、以及属于用户和内容提供商的专有信息。
HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Proxies have access to security-related information, personal information about individual users and organizations, and proprietary information belonging to users and content providers.
代理操作员应保护代理运行的系统,就像他们会保护包含或传输敏感信息的任何系统一样。
Proxy operators should protect the systems on which proxies run as they would protect any system that contains or transports sensitive information.
缓存代理提供了额外的潜在漏洞,因为缓存的内容代表恶意利用的有吸引力的目标。因此,缓存内容应作为敏感信息进行保护。
Caching proxies provide additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Therefore, cache contents should be protected as sensitive information.
HTTP - Message Examples
Example 1
获取 hello.htm 页面的HTTP请求来自tutorialspoint.com上运行的Web服务器
HTTP request to fetch hello.htm page from the web server running on tutorialspoint.com
Example 2
用于获取在运行于 tutorialspoint.com 上的 Web 服务器上不存在的 t.html 页面的 HTTP 请求:
HTTP request to fetch t.html page which does not exist on the web server running on tutorialspoint.com
Client request
GET /t.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Server response
HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: close
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
<title>404 Not Found</title>
</head>
<body>
<h1>Not Found</h1>
<p>The requested URL /t.html was not found on this server.</p>
</body>
</html>
Example 3
用于从运行于 tutorialspoint.com 上的 Web 服务器获取 hello.htm 页面的 HTTP 请求,但是该请求使用错误的 HTTP 版本:
HTTP request to fetch hello.htm page from the web server running on tutorialspoint.com, but request goes with wrong HTTP version:
Client request
GET /hello.htm HTTP1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Server response
HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: close
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
<title>400 Bad Request</title>
</head>
<body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<p>
<p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>
Example 4
用于向运行于 tutorialspoint.com 上的 Web 服务器上的 process.cgi CGI 页面提交表单数据的 HTTP 请求。服务器在将传入的名称设置为 Cookie 后返回它们:
HTTP request to post form data to process.cgi CGI page on a web server running on tutorialspoint.com. Server returns passed name after setting them as cookies:
Client request
POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 60
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
first=Zara&last=Ali
Server response
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 88
Set-Cookie: first=Zara,last=Ali;domain=tutorialspoint.com;Expires=Mon, 19-
Nov-2010 04:38:14 GMT;Path=/
Content-Type: text/html
Connection: Closed
<html>
<body>
<h1>Hello Zara Ali</h1>
</body>
</html>