表单与登录

在网页应用中，不同请求方法承担不同职责。 一般来说，搜索、筛选、查看内容等操作通常使用 GET 请求；而涉及账户密码提交、发表评论、创建文章等会改变服务器状态的操作，通常使用 POST 请求。

观察登录流程与 Payload

以笔趣城网站为例，我们可以从浏览器 Network 面板观察一次真实登录请求。

首先，在页面中点击“会员登录”：

1. 浏览器首先发出 GET /login 请求，获取登录表单页面；
2. 在 Network 面板中勾选 Keep log，或旧版浏览器中对应的 Preserve log，用于防止页面跳转时请求记录被清空；
3. 输入账号 reader、密码 bookworm，然后点击“登录”按钮。

登录请求发出后，可以在 Network 面板中选中捕获到的 POST /login 请求，重点观察请求头和请求体。

通常可以看到：

• 请求头包含 Content-Type: application/x-www-form-urlencoded，说明表单数据使用了常见的 URL 编码格式；
• 查看 Payload，即请求体内容，提交的表单数据如下：

username=reader&password=bookworm

这意味着浏览器将表单中的 username 和 password 字段拼接成键值对，并作为请求体发送给服务器。

登录后的 303 重定向与会话建立

服务器收到 POST /login 请求后，会验证用户名和密码是否正确。 如果登录成功，服务器返回的状态码通常不是 200，而是：

303 See Other

这个响应的关键含义是：服务器告诉浏览器，请求已经处理完成，但后续应该跳转到另一个地址。

具体来说：

• 响应头中可能包含 Location: /bookshelf，表示浏览器需要自动发起 GET /bookshelf 请求，跳转到“我的书架”页面；
• 更重要的是，响应头中可能包含一条 Set-Cookie 指令，用于给浏览器下发身份标识。

Set-Cookie 是建立 Web 会话的重要环节。 服务器通过该响应头向浏览器设置 Cookie，例如登录态、会话 ID 或用户身份信息。 当浏览器随后访问 /bookshelf、/me 或其他需要登录状态的页面时，会自动携带这些 Cookie，服务器据此识别当前请求来自哪个用户。

亲手登录一次，看看登录后才能访问的页面上有什么。