我对标题Location和感到困惑Content-Location。
关于我在规范Content-Location中找到了这个声明。（强调我的）
\n\n对于像 PUT（第 4.3.4 节）或 POST（第 4.3.3 节）这样的状态更改请求，它意味着服务器的响应包含该资源的新表示，从而将其与可能仅报告有关内容的表示区分开来。动作（例如，“成功了！”）。这允许创作应用程序更新其本地副本，而无需后续 GET 请求。
\n
然而，在 mdn 文档中有一个显示相反行为的示例。（强调我的）
\n\n\n该网站返回一条通用的成功消息，确认该帖子已发布。服务器通过 Content-Location 指定新帖子的位置：
\nRun Code Online (Sandbox Code Playgroud)\nHTTP/1.1 201 Created\nContent-Type: text/plain; charset=utf-8\nContent-Location: /my-first-blog-post\n\n\xe2\x9c\x85 Success!\n
这两种说法似乎互相矛盾。
\n现在，我不确定在响应中不包含真实实体的情况下是否应该使用 Content-Location 。
\n规范中有一个关于标题的句子Location。
\n\n对于 201（已创建）响应，位置值是指请求创建的主要资源。
\n
mdn 也是这么说的。
\n\n\n在创建资源的情况下，它指示新创建的资源的 URL。
\n
我很困惑该为不包含该实体的帖子回复选择哪一个。
\n我猜测Location标头最适合稍后可以查看实体的通用发布请求。例如，发布用户并查看它。
带有 202 代码的 POST 响应怎么样？例如，将任务发布到队列时，稍后只能查看任务的状态。所以它不是像用户这样的真实实体。即，根据已发布的任务向 X 客户端发送了一封电子邮件，现在我想传达可以查看状态（待处理、失败或成功）的位置。
\n你是对的，MDN 关于第一个例子的说法是错误的。这个例子：
\nHTTP/1.1 201 Created\nContent-Type: text/plain; charset=utf-8\nContent-Location: /my-first-blog-post\n\n\xe2\x9c\x85 Success!\n由于标头，表明 的内容/my-first-blog-post 是 。\xe2\x9c\x85 Success!Content-Location
鉴于您不想返回新资源的主体，您应该保留Location并省略Content-Location.
如果您有时间：将问题报告给 MDN 维护人员。
\n\n\n带有 202 代码的 POST 响应怎么样？例如，将任务发布到队列时，稍后只能查看任务的状态。所以它不是像用户这样的真实实体。即，根据已发布的任务向 X 客户端发送了一封电子邮件，现在我想传达可以查看状态（待处理、失败或成功）的位置。
\n
我会建议一个Link标题。
| 归档时间： |
|
| 查看次数： |
285 次 |
| 最近记录： |