【http】http头部信息

http头部信息

相关文章

http头部信息

一、http头部信息

通用头部（General Headers）：

Request URL：请求 URL
Request Method：请求方法
Status Code：状态码
Remote Address：远程地址

请求头部（Request Headers）：

User-Agent：指定客户端的用户代理字符串。
Accept：指定客户端能够处理的媒体类型。
Accept-Encoding：指定客户端能够接受的内容编码方式。
Authorization：指定用于身份验证的凭据信息。
Cookie：指定客户端发送的 Cookie 数据。
Referer：指定引荐页面的 URL。
Cache-Control：指定请求/响应的缓存策略。
Connection：指定客户端希望保持持久连接的方式。

响应头部（Response Headers）：

Content-Type：指定响应主体的媒体类型。
Content-Length：指定响应主体的长度。
Server：指定服务器的软件名称和版本。
Set-Cookie：指定服务器发送的 Cookie 数据。
Location：指定重定向的目标 URL。
Last-Modified：指定资源的最后修改时间。
Connection：指示服务器是否愿意保持持久连接。

二、Connection

Connection 是一个重要的 HTTP 头部字段，用于控制客户端和服务器之间的连接行为。它可以在请求头部和响应头部中出现，具体含义略有不同。

在请求头部中：

在请求头部中，Connection 头部用于指示客户端的连接管理偏好。常见的值包括：

keep-alive：表示客户端希望保持持久连接，即在请求完成后保持连接打开，以便在同一个连接上发送多个请求。这有助于减少连接的建立和关闭开销，提高性能。
close：表示客户端要求在请求完成后立即关闭连接。这通常在短暂的通信中使用，或者是为了明确指示客户端不希望继续使用连接。

在响应头部中：

在响应头部中，Connection 头部用于指示服务器的连接管理偏好。常见的值包括：

keep-alive：表示服务器愿意保持连接打开，以便在同一个连接上发送多个响应。这有助于减少服务器的负担和提高性能。
close：表示服务器请求客户端在收到响应后立即关闭连接。这可能是由于服务器资源限制或者为了确保在每个请求/响应周期中都使用独立的连接。

注意事项：

HTTP/1.1 协议默认情况下使用持久连接（Connection: keep-alive），而 HTTP/1.0 则默认不使用（Connection: close）。
在现代的 HTTP 应用中，服务器和客户端通常会自动管理连接，并根据需要选择适当的连接行为，而不需要显式地设置 Connection 头部。
如果请求头和响应头中都出现了 Connection 头部，其值以响应头为准。
Connection 头部是可选的，如果未指定，则默认行为取决于 HTTP 版本和服务器/客户端的配置。

三、Location

Location 是一个常见的 HTTP 响应头部字段，用于指示客户端重定向到的新的 URL 地址。通常在服务器发送 3xx 状态码（重定向状态码）作为响应时，会包含 Location 头部字段。

使用场景：

301 Moved Permanently（永久重定向）：服务器将资源永久移动到了一个新的 URL 地址，客户端应该使用新的 URL 发起请求。
302 Found（临时重定向）：服务器临时将资源移动到了一个新的 URL 地址，客户端应该使用新的 URL 发起请求，但不应该更新书签或缓存。

注意事项：

Location 头部中的 URL 地址可以是绝对路径（包含协议和主机名）或相对路径（相对于当前请求的 URL）。
客户端在收到带有 Location 头部的响应后，会自动根据新的 URL 地址发送新的请求，并且在重定向过程中可能会带上原始请求的一些信息，如请求方法、头部等。

四、Authorization

Authorization 是一个常见的 HTTP 请求头部字段，用于指示客户端请求的身份验证信息。它允许客户端将身份凭证（例如用户名和密码）发送给服务器，以便服务器对客户端进行身份验证。

使用场景：

基本身份验证（Basic Authentication）：在基本身份验证中，客户端将用户名和密码编码成 Base64 格式，并将其包含在 Authorization 头部中发送给服务器。服务器收到请求后解码凭证并验证用户身份。

基本身份验证是最简单和最常见的 HTTP 身份验证方法之一，它通过在请求头部中发送 Base64 编码的用户名和密码来进行身份验证。下面是一个基本身份验证的示例：

假设有一个受保护的资源 /api/protected，需要进行基本身份验证才能访问。客户端发送 HTTP 请求时，需要在请求头部中包含 Authorization 头部，值为 Basic 后跟 Base64 编码的用户名和密码。
1
2
3
GET /api/protected HTTP/1.1 Host: example.com Authorization: Basic dXNlcjpwYXNzd29yZA==

摘要身份验证（Digest Authentication）：在摘要身份验证中，客户端和服务器使用摘要算法对密码进行加密，并将生成的摘要值包含在 Authorization 头部中发送给服务器。服务器收到请求后使用相同的算法验证摘要值。

摘要身份验证（Digest Authentication）是一种安全的 HTTP 身份验证方法，它使用哈希算法对密码进行加密，并在每个请求中包含一个随机生成的 nonce（一次性数字）来增加安全性。下面是一个摘要身份验证的示例：

假设有一个受保护的资源 /api/protected，需要进行摘要身份验证才能访问。客户端发送 HTTP 请求时，需要在请求头部中包含 Authorization 头部，值为 Digest 开头，后跟一系列摘要信息。

GET /api/protected HTTP/1.1
Host: example.com
Authorization: Digest username="user",
                realm="example",
                nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                uri="/api/protected",
                response="3aaf240ff1fb96f80597127042d8d8b2",
                opaque="5ccc069c403ebaf9f0171e9517f40e41"

Bearer 令牌（Bearer Token）：在 OAuth 2.0 和 JWT（JSON Web Token）等认证机制中，客户端通常使用 Bearer 令牌来表示身份凭证，并将令牌包含在 Authorization 头部中发送给服务器。

假设我们有一个基于 OAuth 2.0 的身份验证和授权系统，客户端需要获取访问令牌来访问受保护的资源。以下是一个简单的示例，演示了如何使用 Bearer 令牌进行身份验证：

获取访问令牌：首先，客户端需要通过某种方式获取访问令牌。通常情况下，这会涉及到与身份提供者进行交互，例如登录、授权等过程。在这个示例中，假设客户端已经通过授权码授权流程获取了一个访问令牌。
使用访问令牌：客户端将访问令牌包含在请求的 Authorization 头部中，并将其发送到受保护的资源服务器上。

1
2
3

GET /api/protected HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c