本篇文章将会详细的介绍HTTP头部信息,若大家在使用过程中有不了解的,可以适当参考。
若有问题,欢迎随时私聊!!!
HTTP头部信息是HTTP协议中的一部分,它包含了HTTP请求和响应的元数据信息。HTTP头部由一组由冒号分隔的键值对组成,每个键值对占一行,每行以回车换行符(\r\n)结束。
HTTP头部信息可以包括请求头部和响应头部,它们由不同的作用。
请求头部和响应头部
响应头部包含了服务器发送给客户端的响应信息,例如响应状态码、响应头部字段、响应消息体等等。响应头部的一些常见字段包括:
请求头部包含了客户端发送给服务器的请求信息,例如请求方法(GET、POST等)、请求URL、请求头部字段、请求消息体等等。请求头部的一些常见字段包括:
Accept
指定客户端能够接受的MIME类型列表(响应内容类型)。其格式通常为一个由逗号分隔的MIME类型列表,可以指定多个类型,并按优先级排序。
例如,Accept字段可以设置为"Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8",这表示客户端可以接受的MIME类型包括text/html、application/xhtml+xml、application/xml、image/webp和任何其他类型(/),并按照指定的顺序进行优先级排序。其中,q参数表示该MIME类型的优先级,取值范围为0到1,值越大表示优先级越高,默认值为1。
服务器会根据客户端的Accept字段和服务器可用的MIME类型,选择一个最合适的响应内容类型进行返回。如果服务器无法提供任何一种客户端能够接受的MIME类型,则会返回406 Not Acceptable状态码。
Accept字段还可以指定MIME类型的特定子类型、字符集、压缩算法等信息,例如:
Accept-Encoding: gzip, deflate:指示客户端可以接受的压缩算法,例如gzip和deflate。
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8:指示客户端可以接受的语言类型,例如中文(中国大陆)、中文、英语等,其中q参数表示优先级。
Accept-Charset: utf-8:指示客户端可以接受的字符集,例如UTF-8。
需要注意的是,Accept字段只是客户端向服务器表达其接受内容类型的意愿,服务器并不一定会按照客户端的要求返回响应内容类型,这取决于服务器端的实际情况。
Authorization
Authorization是HTTP请求头中的一个字段,用于携带用户的身份认证信息,以便服务器对用户进行身份验证。该字段通常出现在需要用户进行身份认证的请求中,例如登录、访问需要权限的资源等。
Authorization字段的格式通常为“Authorization: <type> <credentials>”,其中type表示认证类型,credentials表示认证信息。常见的认证类型有以下几种:
1、Basic:基本认证,使用Base64编码的用户名和密码进行认证,格式为“Basic <credentials>”,例如:
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
其中,dXNlcm5hbWU6cGFzc3dvcmQ=为用户名和密码进行Base64编码后的结果。
2、Bearer:令牌认证,使用服务器颁发的访问令牌进行认证,格式为“Bearer <token>”,例如:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
其中,eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c为访问令牌。
3、Digest:摘要认证,使用MD5算法进行认证,格式为“Digest <credentials>”,例如:
Authorization: Digest username="alice", realm="example.com", nonce="abcdefg123456", uri="/resource", response="0a1b2c3d4e5f6g"
其中,username表示用户名,realm表示认证领域,nonce表示服务器生成的随机数,uri表示请求的资源路径,response表示摘要结果。
Authorization字段还可以包含其他认证信息,例如OAuth 2.0认证的access_token和refresh_token等。
Cache-Control
Cache-Control是HTTP请求头和响应头中的一个字段,用于控制缓存机制的行为。该字段指定了客户端和服务器在缓存资源时应该遵循的一些规则,以便优化网络传输和降低延迟。
在请求头中,Cache-Control字段可以用于向服务器传递关于客户端缓存能力和期望的资源缓存时间等信息。常见的值有:
- no-cache:表示不应从缓存中返回资源,必须从原始服务器重新获取。
- no-store:表示不能将资源缓存到客户端或代理服务器中。
- max-age=<seconds>:表示资源的有效期,单位为秒。在此时间内,客户端可以从缓存中获取资源,而无需再次请求服务器。例如,Cache-Control: max-age=3600表示资源可以缓存1个小时。
- min-fresh=<seconds>:表示客户端希望获取的资源在指定时间内保持新鲜,单位为秒。例如,Cache-Control: min-fresh=60表示客户端希望获取的资源在未来60秒内都是新鲜的。
- max-stale[=<seconds>]:表示客户端可以接受已经过期的资源,但资源的过期时间不能超过指定时间。例如,Cache-Control: max-stale=3600表示客户端可以接受过期时间不超过1个小时的资源。
在响应头中,Cache-Control字段可以用于指示客户端和中间代理如何缓存响应,常见的值有:
- public:表示响应可以被任何中间代理缓存。
- private:表示响应只能被单个用户缓存,中间代理不能缓存。
- no-cache:表示响应必须重新获取,但可以被中间代理缓存。
- no-store:表示响应不能被缓存。
- max-age=<seconds>:表示响应可以被缓存的最长时间,单位为秒。
- must-revalidate:表示客户端必须在缓存过期前重新验证响应。
Cache-Control字段的值可以组合使用,以便更精细地控制缓存行为。例如,Cache-Control: public, max-age=3600表示响应可以被任何中间代理缓存,并且缓存有效期为1个小时。
Connection
HTTP头部字段中的Connection字段用于指定客户端和服务器之间连接的选项。它包含一个逗号分隔的选项列表,每个选项代表一种连接的属性或选项。
常见的Connection选项包括:
- close:表示客户端和服务器之间的连接在响应结束后会关闭,需要重新建立连接才能发送新的请求。
- keep-alive:表示客户端和服务器之间的连接会保持持久化,可以在同一连接上发送多个请求和响应。这样可以减少每次请求时建立和断开连接的开销,提高网络传输的效率。
- Upgrade:表示客户端请求升级到一个不同的协议,例如从HTTP/1.1升级到WebSocket协议。
如果Connection字段的值为close,则表示这个请求处理结束后,连接将会关闭,需要重新建立连接才能发送新的请求。如果Connection字段的值为keep-alive,则表示这个请求处理结束后,连接将会保持打开状态,可以在同一连接上发送多个请求和响应,直到客户端或服务器指定关闭连接。
需要注意的是,由于HTTP/1.1默认使用持久连接(keep-alive),因此如果客户端未指定Connection头部字段,服务器将默认使用持久连接。如果客户端想要关闭持久连接,可以在请求头部中添加Connection: close字段。
Content-Length
Content-Length是HTTP头部字段之一,用于指示消息主体(body)的长度。它通常在POST请求或响应中使用。
Content-Length的值是一个十进制数字,表示消息主体的字节数。例如,如果消息主体包含1000个字节的数据,则Content-Length的值应该为1000。
服务器接收到一个带有Content-Length头部字段的请求时,会在读取指定长度的数据后停止读取,以避免读取超过消息主体长度的无效数据。同样的,客户端在发送消息主体时,需要确保发送的字节数和Content-Length指定的字节数相同,否则服务器可能无法正确处理请求。
需要注意的是,Content-Length只用于指示消息主体的长度,并不包括HTTP头部字段的长度。如果使用HTTP分块编码(chunked)传输,则Content-Length头部字段通常会被省略。
Content-Type
Content-Type是HTTP头部字段之一,用于指示HTTP消息主体(body)的媒体类型。它告诉接收方如何解析HTTP消息主体的数据。
Content-Type头部字段通常在HTTP请求和响应中使用。在HTTP请求中,它告诉服务器要求的媒体类型;在HTTP响应中,它告诉客户端服务器返回的媒体类型。
Content-Type的值通常由两个部分组成,第一个部分是媒体类型,第二个部分是媒体子类型,两者之间用斜杠(/)分隔。例如,常见的Content-Type值有:
- text/html:表示HTML文档;
- application/json:表示JSON数据;
- image/png:表示PNG格式的图片;
- audio/mpeg:表示MP3格式的音频。
Content-Type头部字段还可以包含参数,用于指定编码方式、语言等相关信息。例如,Content-Type头部字段可以包含charset参数,指定字符编码方式,如Content-Type: text/html; charset=UTF-8。
需要注意的是,Content-Type是HTTP消息主体的必须字段之一,没有正确指定Content-Type可能会导致接收方无法正确解析HTTP消息主体。
Cookie
Cookie是一种在客户端(通常是Web浏览器)和服务器之间传递信息的机制。在HTTP协议中,Cookie是通过HTTP头部字段Set-Cookie和Cookie来进行传输的。
当Web服务器向客户端发送HTTP响应时,可以通过Set-Cookie头部字段在客户端创建一个Cookie。客户端可以将Cookie存储在本地,并在随后的每个请求中将Cookie发送回服务器。服务器可以读取Cookie中的信息,根据它来执行一些操作,例如认证用户、记录用户行为等。
Cookie通常用于保存会话信息、用户偏好设置等,以提高Web应用程序的用户体验。例如,当用户在一个电子商务网站中添加商品到购物车时,可以使用Cookie来保存购物车信息,以便用户在浏览其他页面时保留购物车内容。另外,Cookie还可以用于实现用户身份验证,例如记住用户的登录信息,允许用户在浏览器关闭后再次登录而不必重新输入用户名和密码。
需要注意的是,Cookie是一种不安全的机制,因为Cookie存储在客户端本地,有可能被攻击者窃取或篡改。因此,在设计和实现Web应用程序时,需要注意Cookie的安全性,并采取相应的安全措施,例如对Cookie进行加密、签名等。
Date
Date头部字段是HTTP协议中用于指定HTTP消息创建的日期和时间的头部字段。它通常用于跟踪Web服务器或代理服务器的时间,并可以用于计算缓存的内容是否已过期。
HTTP消息的日期和时间可以在多个地方进行指定,例如在请求行中、响应行中、响应头部或请求头部中。在响应头部中,Date字段指示HTTP响应消息的创建日期和时间,格式为:
Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
其中,<day-name>
是星期几的英文缩写,<day>
是月中的日期,<month>
是英文缩写的月份,<year>
是四位数的年份,<hour>
、<minute>
和<second>
分别是时、分和秒,都用两位数表示。GMT是指格林威治标准时间。
Date字段可以帮助Web服务器和代理服务器协调彼此之间的时间,以确保缓存的内容在正确的时间过期,并避免在处理HTTP请求和响应时出现时间戳不一致的问题。另外,Date字段还可以用于调试和排除故障,因为它可以显示HTTP消息的创建时间。
需要注意的是,由于客户端和服务器之间的时间可能存在偏差,因此不建议将Date字段用于计算实际时间,例如计费或事件记录。在这种情况下,应使用更精确的时间同步机制,例如使用网络时间协议(NTP)。
Expect
Expect
是 HTTP 请求头部中的一个字段,它用来告诉服务器客户端在请求处理期间期望的行为。通常它用于支持 HTTP 100 Continue 机制,该机制允许客户端在等待服务器处理完整个请求之前发送一个大的请求体。
Expect
请求头字段可以包含以下值:
-
100-continue
: 表示客户端期望服务器在发送请求体之前确认请求是否可以接受。如果服务器回复一个100 Continue
,则客户端可以发送请求体。
From
在HTTP请求中,From
头字段用于指示发起请求的用户的电子邮件地址。该字段主要用于记录和跟踪,不用于身份验证或授权。
一般来说,From
字段的值应该是一个电子邮件地址,例如:
From: user@example.com
但是,该字段也可以包含其他信息,例如发起请求的用户的姓名和组织等,例如:
From: John Smith <user@example.com>
该字段在HTTP请求中不是必需的,而且在实际使用中也不常用。
Host
在HTTP请求中,Host
头字段用于指示请求的目标主机的主机名或IP地址。在HTTP/1.1协议中,所有的HTTP请求都必须包含该字段。
例如,如果一个客户端想要请求example.com
网站的首页,它会向该网站发送如下请求:
GET / HTTP/1.1 Host: example.com
在上述请求中,Host
字段的值是example.com
,表示该请求的目标主机是example.com
网站。
如果一个HTTP请求中不包含Host
头字段,或者该字段的值为空,服务器将无法确定请求的目标主机,因此该请求将被视为无效请求并被拒绝。
需要注意的是,对于使用虚拟主机技术的Web服务器,Host
头字段还可以用于指示请求的具体虚拟主机。例如,如果一个Web服务器上托管了多个虚拟主机,每个虚拟主机都有自己的域名或主机名,那么客户端可以通过在Host
字段中指定目标虚拟主机的域名或主机名来请求该虚拟主机的内容。
If-Match
If-Match是一个HTTP请求头部字段,用于在使用HTTP方法(如PUT,POST等)对资源进行更新时检查资源状态。该字段值是一个用双引号括起来的实体标签,代表对资源的ETag值进行匹配。
当发送具有If-Match头部的请求时,服务器会比较请求中的实体标签和服务器上实际资源的ETag值。如果两者匹配,则请求将被处理。如果它们不匹配,服务器将返回一个状态码为412(Precondition Failed)的响应,并且不会进行请求。
这个头部通常与其他头部(如ETag和Last-Modified)一起使用,以确保在多个客户端之间正确地维护资源的状态。
If-Modified-Since
If-Modified-Since是一个HTTP请求头部字段,用于向服务器询问资源是否在指定日期后修改过。该字段值是一个日期时间字符串,用于表示客户端最后一次获取资源的时间。服务器会将请求中的时间戳与资源的修改时间进行比较,以确定是否应该返回资源的新版本。
如果资源在指定时间后未进行修改,则服务器会返回HTTP状态码为304(Not Modified)的响应,并告诉客户端使用缓存中的资源。如果资源已经被修改,则服务器将返回新版本的资源,并使用状态码200(OK)或其他适当的状态码。
使用If-Modified-Since头部可以减少网络流量和服务器负载,因为客户端可以避免重复请求未发生更改的资源。这对于缓存或响应较慢的服务器非常有用。
If-None-Match
If-None-Match 是 HTTP 请求头中的一个字段,用于条件请求。它的作用是告诉服务器只有在客户端提供的 ETag 值和服务器中资源的 ETag 值不一致时,服务器才会返回实体内容,否则返回 304 Not Modified 响应,客户端使用缓存的实体。
如果客户端在之前的请求中使用了 If-None-Match 请求头,那么服务器在返回响应时会包含 ETag 响应头,该响应头的值就是服务器中该资源的 ETag 值。客户端在后续的请求中再次使用 If-None-Match 请求头时,就会将之前响应头中的 ETag 值带上,如果服务器判断两个值一致,就会返回 304 响应。
使用 If-None-Match 请求头能够减少不必要的数据传输,减轻服务器压力,提高响应速度。
If-Range
If-Range 是一个条件请求标头,在使用范围请求时,它可用于确保服务器返回的部分响应仍然是最新的。该标头包含一个实体标记(ETag)或日期时间值,它与所请求的范围匹配。如果实体标记或日期时间值与服务器上的当前实体匹配,则服务器将返回所请求的范围的内容,否则,它将返回完整的实体内容。
例如,如果客户端只需要文档的一部分,但希望确保该部分的实体标记与服务器上的实体标记匹配,则客户端可以使用 If-Range 头部来检查。
示例:
If-Range: "etag-value" If-Range: Sun, 06 Nov 1994 08:49:37 GMT
在第一个示例中,客户端希望服务器使用实体标记值 "etag-value" 进行比较。在第二个示例中,客户端希望服务器使用时间戳 Sun, 06 Nov 1994 08:49:37 GMT 进行比较。
如果 If-Range 头部值与实体匹配,则服务器将返回请求范围内的内容,否则将返回整个实体内容。
If-Unmodified-Since
If-Unmodified-Since
是一个 HTTP 请求头部,在使用 PUT 或者其他一些需要检查修改时间的请求时使用,它指定了服务器文件的最后修改时间,如果该时间与指定的时间一致,服务器将执行请求操作,否则将返回状态码为 412
的响应。
该字段的值应该是一个 HTTP-date 格式的时间戳,例如:Sat, 29 Oct 1994 19:43:31 GMT
。
下面是一个 If-Unmodified-Since
请求头部的示例:
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Max-Forwards
Max-Forwards是一个HTTP请求头部字段,用于限制消息在传输过程中通过代理或网关转发的最大次数。其值是一个非负整数。
当一个HTTP请求被发送时,这个请求头部字段的值被设置为一个初始值。当这个请求经过代理或网关时,这个值会被递减。如果这个值达到了0,那么消息就不会被转发,而是返回一个“413 Request Entity Too Large”的响应。
这个字段通常用于防止消息在代理或网关之间无限循环。
Pragma
Pragma 是 HTTP/1.0 中的一个头部字段,用于向服务器传递指令或指示性信息,以改变服务器或客户端的行为。它可以包含多个指令,每个指令用逗号隔开。
常见的指令包括:
- no-cache:强制要求服务器在返回响应之前验证资源是否发生了更改,并在必要时重新获取最新版本的资源。
- no-store:指示服务器不要将响应存储在任何缓存中,包括本地缓存和共享缓存中。
- must-revalidate:告诉缓存必须验证缓存条目的状态,而不能仅仅依靠已过期的缓存来响应请求。
- max-age:告诉缓存可以缓存响应的最长时间,以秒为单位。
Pragma 已经被 HTTP/1.1 中的 Cache-Control 头部字段所取代,虽然现在很少使用,但在某些情况下仍然有用。
Proxy-Authorization
Proxy-Authorization是HTTP请求头部中的一项,用于在HTTP请求中传递代理服务器所需的客户端身份验证信息。
当客户端需要通过代理服务器来访问另一个服务器时,代理服务器可能会要求客户端提供身份验证信息。此时,客户端需要在请求头中使用Proxy-Authorization字段来传递用户名和密码等身份验证信息给代理服务器。代理服务器会根据这些信息来验证客户端的身份是否合法,如果合法,就会将客户端请求转发到目标服务器。
Proxy-Authorization头部字段通常与Proxy-Authenticate头部字段一起使用。当代理服务器需要进行身份验证时,会向客户端发送一个Proxy-Authenticate头部字段,其中包含代理服务器要求客户端提供的身份验证信息。客户端在接收到Proxy-Authenticate头部字段后,需要在下一次请求中使用Proxy-Authorization头部字段来传递身份验证信息。
需要注意的是,Proxy-Authorization头部字段中的身份验证信息应该是经过编码的,一般使用Base64编码算法进行编码。
Range
Range是HTTP请求头部字段之一,用于指定请求的资源的范围,常用于分块下载或视频播放等场景。该字段指定的范围是以字节为单位的,格式为"bytes=<start>-<end>",其中start和end分别表示请求的起始和终止字节位置。若start或end被省略,则表示从文件开头或文件结尾处开始请求。
例如,如果要请求一个文件的前500个字节,可以使用以下请求头部:
Range: bytes=0-499
服务器可以根据Range字段返回相应的资源的一部分,响应头部中的Content-Range字段指定了返回的资源的范围及总大小。
值得注意的是,服务器并不一定支持Range字段,因此客户端在请求时需要先检查服务器是否支持该字段。服务器可以在响应头部中使用Accept-Ranges字段指示其是否支持Range请求。
Referer
Referer是HTTP头部字段之一,它用于指示请求的来源页面或URL。当用户通过点击链接或提交表单等方式访问一个页面时,浏览器会在HTTP请求头部中包含Referer字段,该字段的值为访问前一个页面的URL。
Referer字段有助于网站管理员了解访问来源和路径,也可以用于一些反欺诈和安全方面的应用。但需要注意的是,Referer字段的使用可能会泄露用户的隐私信息,因此需要谨慎处理。
例如,一个站点的页面A中包含一个链接指向站点B,当用户点击该链接时,浏览器会向站点B发送一个请求,并在请求头部中包含Referer字段,其值为页面A的URL。站点B可以根据Referer字段判断用户是从哪个页面跳转过来的,从而进行一些特定的处理。
TE
TE是HTTP头部字段之一,指定响应可接受的传输编码方式。它通常被用于向服务器表明客户端能够解码响应的方式。
TE头部字段是HTTP/1.1协议中定义的,用于表示客户端能够接受的传输编码方式。它的格式为:
TE: encoding1, encoding2, ...
其中,encoding是传输编码的名称。如果客户端不支持任何传输编码方式,则可以发送TE: identity字段,表示不需要进行传输编码。
在服务器响应请求时,如果能够进行传输编码,则应该在响应头中使用Transfer-Encoding头部字段来表示。常见的传输编码方式有chunked和gzip等。如果客户端不支持响应的传输编码方式,则服务器可以返回不进行传输编码的原始数据,或者发送406 Not Acceptable状态码,表示客户端发送了不支持的TE值。
需要注意的是,TE头部字段只适用于客户端指定自己接受的传输编码方式,而不适用于服务器指定响应的传输编码方式。服务器可以使用Content-Encoding头部字段来表示响应所采用的传输编码方式。
Upgrade
Upgrade是HTTP头部字段之一,它指定了客户端愿意接受哪些协议来响应当前请求,或者客户端要求服务器升级到某些协议。
具体来说,Upgrade字段的格式如下:
Upgrade: <protocol> | <protocol>/<version>
其中<protocol>
是指要升级到的协议的名称,例如HTTP/2.0
,而<version>
则是指该协议的版本号。
客户端在发送HTTP请求时,如果想要升级到某个协议,可以在请求头中添加Upgrade字段来指定。服务器在响应时,可以使用Upgrade字段来指定所支持的协议,并在响应中添加一个101 Switching Protocols
的状态码。
Upgrade字段通常用于支持长连接,例如使用WebSocket协议时可以通过Upgrade升级HTTP协议。
User-Agent
User-Agent 是 HTTP 请求头部中的一个字段,用于标识发出请求的客户端类型、操作系统、软件应用程序等信息。服务器可以根据 User-Agent 字段来返回不同的内容,比如在移动设备上返回针对移动设备优化的内容。
该字段的值通常包括以下信息:
- 应用程序名称和版本号
- 操作系统名称和版本号
- 浏览器内核类型和版本号
- 浏览器类型和版本号
- 硬件类型
例如,一款浏览器的 User-Agent 字段可能如下所示:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36
其中,"Mozilla/5.0" 表示该请求遵循 Mozilla 协议,"Windows NT 10.0; Win64; x64" 表示操作系统为 Windows 10 64 位,"AppleWebKit/537.36" 表示浏览器内核为 WebKit 537.36,"Chrome/93.0.4577.63" 表示浏览器为 Chrome 93.0.4577.63 版本,"Safari/537.36" 表示浏览器采用 Safari 的渲染引擎。
Via
Via是HTTP头部字段之一,它用于表示代理服务器和客户端之间的中间代理节点。当请求通过多个代理服务器传输时,每个代理服务器都会向请求头部添加一个Via字段,其中包含了代理服务器的相关信息,如服务器名称、版本号等等。这样,接收到请求的服务器就能够了解请求的路径,以及经过的中间代理节点的信息。
Via字段的格式通常是由协议版本、代理服务器名称和可选的注释组成,各个部分之间用空格分隔。例如,一个简单的Via字段可能是:HTTP/1.1 proxy1 (其中,HTTP/1.1是协议版本,proxy1是代理服务器名称)。
需要注意的是,由于Via字段是由代理服务器添加的,因此该字段在请求和响应之间可能会发生变化。另外,如果请求中包含多个Via字段,那么这些字段的顺序通常是由代理服务器的先后顺序决定的,因此接收到请求的服务器需要按照逆序处理这些Via字段。
Warning
Warning
是 HTTP 响应头部字段之一,用于提供有关消息的附加信息。它表示在服务器上发生了一些异常情况,但是这些情况不会导致请求失败或响应不可用。通常,Warning
是一个告警,需要客户端开发人员或管理员进行注意或处理。
Warning
头部字段由以下信息组成:
-
code
:一个三位数的警告码,指示警告的类型。代码由三个数字组成,第一个数字表示警告的重要性,第二个数字表示警告组件的类型,第三个数字表示特定的警告。 -
agent
:指示生成警告的服务器应用程序。 -
text
:描述警告的可读文本。
例如,以下是一个包含 Warning
头部字段的 HTTP 响应示例:
HTTP/1.1 200 OK Date: Mon, 10 May 2023 05:12:00 GMT Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/7.2.17 Warning: 214 - "Transformation applied" Content-Length: 1234 Content-Type: text/html; charset=UTF-8
这个示例中,Warning
头部字段的值为 "214 - "Transformation applied"",表示在服务器上应用了某种转换,但是转换可能会导致一些问题。
Accept-Ranges
Accept-Ranges
是一个响应头部字段,用于指示服务器是否支持范围请求,以及支持哪些类型的范围请求。范围请求是指客户端在请求资源时可以指定一个字节范围,服务器则只返回该范围内的内容。
该字段的值可以是 bytes
或者 none
。bytes
表示服务器支持范围请求,可以通过指定 Range
头部来请求部分资源;none
表示服务器不支持范围请求。
例如,服务器可以返回以下响应头部:
HTTP/1.1 200 OK Accept-Ranges: bytes
表示该服务器支持范围请求,可以通过指定 Range
头部来请求部分资源。
Age
Age
是一个响应头部字段,用于指示一个响应消息从原始服务器生成后,被代理服务器缓存了多长时间(以秒为单位),表示服务器已经将响应存储在缓存中了多久。
当客户端从代理服务器获取响应时,代理服务器将使用 Age
字段计算出最后响应的年龄,并将其添加到 Age
字段中,然后将响应发送给客户端。这可以帮助客户端判断响应是否仍然有效。
Age
字段常常与 Cache-Control
和 Expires
字段一起使用,用于控制响应在代理服务器上的缓存时间以及在客户端上的有效期。
ETag
ETag是HTTP头部中的一个字段,全称是“Entity Tag”,实体标签,用于唯一地标识一个HTTP请求返回的资源。它可以是任何类型的数据,如文本、图像、视频等等。
ETag可以与其他缓存控制头部一起使用,例如Cache-Control和Expires,以帮助确定客户端如何处理缓存。当客户端请求一个资源时,它会在请求头中发送If-None-Match字段,并将上次请求返回的ETag值发送给服务器。如果服务器发现该资源的ETag值与客户端发送的ETag值匹配,则返回304 Not Modified响应,告诉客户端使用其缓存副本,从而减少网络流量和提高响应速度。
ETag还可以用于解决并发访问的问题。例如,当多个客户端同时请求同一个资源时,服务器可以为每个请求生成一个唯一的ETag值。这样,当一个客户端成功请求到资源时,其他客户端的请求可以使用返回的ETag值作为条件,以避免重复下载相同的资源。
Expires
Expires
是 HTTP 响应头部字段之一,它指定了响应内容的过期时间,即该响应被认为是无效的时间点。当客户端收到一个过期时间早于当前时间的响应时,客户端就会认为该响应是无效的,因此不会使用它,而是向服务器发起新的请求。
Expires
的值通常是一个 HTTP 日期,例如 "Sat, 01 Jan 2000 00:00:00 GMT"。它表示了一个绝对时间,而不是一个时间段,因此必须与客户端的时间同步。
在 HTTP/1.1 中,Expires
字段被 Cache-Control
字段所取代。如果同时出现这两个字段,则 Cache-Control
的优先级更高。
Last-Modified
Last-Modified
是一个HTTP响应头部字段,用于指示服务器最后修改资源的日期和时间。它通常在HTTP GET请求的响应中出现,可以帮助客户端(例如浏览器)判断缓存是否有效,以便在必要时更新本地缓存。
具体来说,当浏览器发送一个HTTP GET请求时,服务器会响应一个带有Last-Modified
头部字段的响应。浏览器将此头部字段存储在缓存中,以便下一次请求该资源时可以将其发送到服务器。如果在下一次请求中,浏览器发现该资源的Last-Modified
日期与其缓存中的日期不同,它将向服务器发送一个新的HTTP GET请求,以获取最新的版本。
Last-Modified
的日期格式通常使用HTTP日期格式,例如:Sat, 29 Oct 1994 19:43:31 GMT。
示例:
Last-Modified: Tue, 04 May 2021 15:26:16 GMT
Location
Location
是一个响应头部字段,用于指示客户端请求的资源的位置。
具体来说,当服务器收到客户端的请求,并发现该请求需要重定向到另一个 URL 地址时,就可以使用 Location
头部字段。在响应中,该字段告诉客户端要访问的新的 URL 地址。客户端可以根据这个新地址发出新的请求来获取所需资源。
例如,在用户登录后,服务器可能需要将用户重定向到他们的个人资料页面。服务器将发送一个带有 Location
头部字段的响应,其中包含用户资料页面的 URL。客户端将在接收到这个响应后发出新的请求,并获取用户资料页面。
示例响应:
HTTP/1.1 302 Found Location: https://www.example.com/user/profile
在上面的示例中,服务器返回了一个 302 状态码,并将重定向目标 URL 放在 Location
头部字段中。
Retry-After
Retry-After
是一个响应头部字段,用于指示客户端在重试之前应等待的时间(以秒为单位),以避免过多的请求。它可以用于以下情况:
- 服务器过载或维护,需要客户端等待一段时间后再重试。
- 客户端进行了过多的请求,服务器需要客户端等待一段时间后再重试。
- 由于某种原因,请求失败,但是在一段时间后可能会成功。
如果字段值为整数,则表示应等待的秒数。如果它是日期/时间字符串,则表示在指定的日期/时间之后再进行重试。如果未指定值,则默认情况下,客户端应在一定的时间内重试。
示例:
Retry-After: 120
这表示客户端应该等待 120 秒(即 2 分钟)后再尝试请求。
Server
Server
是 HTTP 响应头部中的一个字段,用于指示响应的服务器软件名称和版本。它通常被用于在客户端与服务器之间交流时,确认响应是由哪个服务器软件产生的。
例如,一个典型的 Server
响应头部看起来可能是这样的:
Server: Apache/2.4.46 (Unix) OpenSSL/1.1.1j PHP/7.4.16
在这个例子中,Server
字段显示了响应的服务器是 Apache 版本 2.4.46,使用了 OpenSSL 版本 1.1.1j 和 PHP 版本 7.4.16。
需要注意的是,Server
字段并不是必需的,因此某些响应可能不包含该字段。此外,为了提高安全性,一些网站可能会更改服务器软件的名称或隐藏 Server
字段。
Set-Cookie
Set-Cookie
是一个响应头部字段,用于在服务器端向客户端设置一个或多个 Cookie。
具体来说,当服务器向客户端发送响应时,可以使用 Set-Cookie
头部字段在响应中包含一个或多个 Cookie。一个 Cookie 是一个包含了名称、值、域、路径、过期时间和其它属性的文本文件,存储在客户端浏览器上。当客户端随后向服务器发送请求时,浏览器会自动将 Cookie 添加到请求中,以便服务器可以获取 Cookie 的值并执行相关操作。
以下是 Set-Cookie
头部字段的一个示例:
Set-Cookie: name=value; Expires=Wed, 21 Oct 2023 07:28:00 GMT; Path=/
其中,name=value
表示 Cookie 的名称和值,Expires
指定了 Cookie 的过期时间,Path
指定了 Cookie 的作用范围。除了这些参数外,Set-Cookie
还可以包括许多其他属性,例如 Domain
、Secure
、HttpOnly
等。
需要注意的是,每个 Set-Cookie
响应头部字段只能包含一个 Cookie。如果服务器想要设置多个 Cookie,则需要发送多个 Set-Cookie
响应头部字段。
Transfer-Encoding
Transfer-Encoding是HTTP头部字段之一,用于指示传输编码方式。它是一种在传输过程中对实体内容进行编码的方式,通常用于压缩或分块传输。
常见的传输编码方式包括:
- chunked:将实体分成若干块(chunk),每一块都用16进制表示的大小和实体内容组成。
- compress:使用UNIX“compress”程序的简单数据压缩算法进行编码。
- deflate:使用 zlib 结构(在 RFC 1950 中定义)的方法进行编码。
- gzip:使用 gzip 压缩算法进行编码。
- identity:未进行编码,即“原样传输”。
服务器在响应头部中使用Transfer-Encoding字段指定传输编码方式,客户端在请求头部中使用TE字段请求指定的传输编码方式。
Vary
Vary 是 HTTP 响应头部字段之一,用于指示代理服务器在缓存响应时必须考虑的请求头部字段。
当 Vary 字段包含某些请求头部字段时,代理服务器会在缓存响应之前检查这些请求头部字段。如果请求头部字段的值与之前缓存的响应不匹配,代理服务器会向原始服务器请求新的响应。
Vary 字段的值是一个逗号分隔的列表,列出了代理服务器需要考虑的请求头部字段。例如,如果 Vary 的值为 "User-Agent",则代理服务器会根据 User-Agent 请求头部字段缓存响应。
WWW-Authenticate
WWW-Authenticate 是一个响应头部,它被用于指示客户端进行身份验证。当 Web 服务器需要验证客户端身份时,它会向客户端发送一个带有 WWW-Authenticate 头部的 401 状态码响应。WWW-Authenticate 头部包含一个身份验证方法,这个方法由服务器定义。客户端将使用这种方法提交其证书或证书请求,以验证其身份。
举个例子,当你试图访问一个需要登录的网站时,如果你没有登录,你会被重定向到登录页面。此时,登录页面的 HTTP 响应头部中将包含一个带有 WWW-Authenticate 头部的 401 状态码响应。这个 WWW-Authenticate 头部指示客户端需要进行身份验证,并说明了身份验证方法(如 Basic 或 Digest)以及相关参数,比如 realm(领域)。
客户端会根据这个头部中指定的身份验证方法,提交相应的证书或证书请求,以验证身份。如果客户端的身份验证成功,它就可以继续访问被保护的资源。
HTTP头部信息允许客户端和服务器之间传递一些额外的信息,从而增强了HTTP协议的灵活性和扩展性。