表单提交以外的 HTTP 请求的 MIME 类型答案

【问题标题】：MIME type for HTTP requests other than form submissions表单提交以外的 HTTP 请求的 MIME 类型
【发布时间】：2012-08-11 02:40:12
【问题描述】：

对于不是由 HTML 表单发送的请求，HTTP 是否将请求的 Content-Type 限制为 application/x-www-form-urlencoded 以进行非文件上传，或者该 MIME 类型是否“正确”/标准/语义上有意义还有其他方式吗？

例如，PHP 自动将内容解析为 $_POST，这似乎表明 x-www-form-urlencoded 是服务器期望的。另一方面，我可以使用 Ajax 在 HTTP 请求内容中发送一个 JSON 对象，并将 Content-Type 设置为 application/json。至少某些服务器技术（例如 WSGI）不会尝试解析它，而是以原始形式将其提供给脚本。

我应该在 RESTful API 中的 POST 和 PUT 请求中使用哪种 MIME 类型，以确保符合 HTTP 的所有服务器实现？我忽略了诸如 SOAP 和 JSON-RPC 之类的技术，因为它们通过 HTTP 隧道协议，而不是按预期使用 HTTP。

【问题讨论】：

标签： http post http-headers put http-request

【解决方案1】：

简答

您应该指定最能描述 HTTP 消息实体主体的内容类型。

长答案

例如 PHP 自动将内容解析成 $_POST，这似乎表明 x-www-form-urlencoded 是服务器期望的。

服务器没有“期待”x-www-form-urlencoded。 PHP——为了让开发人员的生活更简单——将把表单编码的实体主体解析为$_POST超全局当且仅当Content-Type: x-www-form-urlencoded并且实体主体实际上是一个urlencoded键值字符串。对于以Content-Type: multipart/form-data 到达的消息，遵循类似的过程以生成$_FILES 数组。虽然很有帮助，但不幸的是，这些超全局变量被命名了，它们混淆了实际 HTTP 事务中真正发生的事情。

我应该在 RESTful API 的 POST 和 PUT 请求中使用什么 MIME 类型以确保符合 HTTP 的所有服务器实现？

您应该指定最能描述 HTTP 消息实体主体的内容类型。始终遵守官方的 HTTP 规范——如果你这样做，你就不会出错。来自RFC 2616 Sec 7.2.1（强调）：

任何包含实体主体的 HTTP/1.1 消息都应该包含一个定义该主体的媒体类型的 Content-Type 标头字段。 如果和仅当媒体类型不是由 Content-Type 字段给出时，接收者可以尝试通过检查其媒体类型来猜测媒体类型 URI 的内容和/或名称扩展名，用于标识资源。如果媒体类型仍然未知，接收者应该将其视为“application/octet-stream”类型。

任何主流服务器技术都将遵守这些规则。周到的 Web 应用程序不会信任您的 Content-Type 标头，因为它可能正确也可能不正确。消息的发起者可以随意发送完全虚假的值。通常检查Content-Type标头作为初步验证措施，但通过解析实际数据进一步验证内容。例如，如果您将 JSON 数据放入 REST 服务，端点可能会首先检查以确保您已发送 Content-Type: application/json，然后实际解析消息的实体主体以确保它确实是有效的 JSON。

【讨论】：