php header 不分大小写的吗,HTTP标头区分大小写吗？

最新推荐文章于 2024-07-25 07:26:22 发布

张奈儿

最新推荐文章于 2024-07-25 07:26:22 发布

阅读量1.2k

点赞数

文章标签： php header 不分大小写的吗

本文探讨了HTTP头部字段名称是否区分大小写的问题，并指出HTTP/1.1和HTTP/2中头部字段名称均不区分大小写。同时，讨论了Content-Type头部中charset参数的有效性及其在实际应用中的作用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在博客文章中，我使用以下PHP来设置响应的内容类型：

header('content-type: application/json; charset=utf-8');

我刚刚对该帖子发表评论说content-type需要大写，content-type。这个对吗？它似乎适用于所有小写的我，我假设HTTP标题不区分大小写。或者它只是工作，因为浏览器很好？

它的大小写不敏感，但是如果你要解决这个问题，它应该是Content-Type。

FWIW，使用application / json发送"charset"是没有意义的。没有这样的参数。

@JulianReschke - 这是假的，charset是Content-Type标头中的有效参数。参见w3.org/International/articles/http-charset/index和developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type

@cchamberlain - 在"applocation / json"中毫无意义。该媒体类型没有此类参数。

@JulianReschke添加参数没有任何缺点。此外，甚至有一些应用程序/库将不会工作，除非它包含一个charset参数。另一方面，不期望charset参数的应用程序将继续正常工作，如果您添加它。

@NullUserException - 缺点(除了浪费的字节)是继续让人们对charset param感到困惑。只需修复这些组件即可。

@JulianReschke是对的。 IANA应用程序/ json任务说charset对于这种媒体类型毫无意义。它没有做任何事情。请不要添加它，因为它的噪音会导致不必要的混淆。

charset包含是否能够面向未来？让我们假设你的json中有国际化模板... charset = utf-16/32？

我猜可能不会，泰斯。 JSON被指定为仅以UTF-8，UTF-16或UTF-32编码;其他任何东西，它不是JSON。那些是编码，而不是字符集(尽管"charset"对于这种区别是模糊的) - 它们都是相同字符集的编码，即Unicode的编码。该规范还要求该算法仅从内容中确定正确的编码，因此可能包含此问题的唯一原因是解决软件中的错误，这些错误都会错误地读取JSON和内容类型标头。

标题名称不区分大小写。

从RFC 2616 -"超文本传输??协议 - HTTP / 1.1"，第4.2节"消息头"：

Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.

更新RFC 7230未列出此部分RFC 2616的任何更改。

答案仍然是正确的，RFC 7230声明："每个头字段包含一个不区分大小写的字段名称后跟一个冒号("：")，可选的前导空格，字段值和可选的尾随空格。"

使用PHP以使用方法apache_request_headers()获取标头字段的值时，标头字段区分大小写。

任何人都可以提供不符合这方面规范的流行浏览器示例吗？

@Harm只是因为PHP中的字符串比较区分大小写。

对于任何人来说，这里是RFC 7230明确声明字段标题应被视为不区分大小写的地方：tools.ietf.org/html/rfc7230#section-3.2

随机事实：某些系统(AWS CloudFront为1)可能会在重写标头时利用标准的这一部分。我已经意外地改变了标题键的情况 - 下次很高兴知道

标题字段值怎么样？

@JoeCodeFrog：标题字段值是应用程序定义的;您需要查阅正在使用的特定应用程序的文档。

根据RFC 2616，HTTP标头名称不区分大小写：

4.2：

Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.

(字段值可能区分大小写，也可能不区分大小写。)

如果您信任主流浏览器遵守此规则，那么您已经完成了所有设置。

BTW，与大多数HTTP不同，方法(动词)区分大小写：

5.1.1方法

The Method token indicates the

method to be performed on the

resource identified by the

Request-URI. The method is

case-sensitive.

Method ="OPTIONS" ; Section 9.2

|"GET" ; Section 9.3

|"HEAD" ; Section 9.4

|"POST" ; Section 9.5

|"PUT" ; Section 9.6

|"DELETE" ; Section 9.7

|"TRACE" ; Section 9.8

|"CONNECT" ; Section 9.9

| extension-method

extension-method = token

+1提及HTTP动词的情况

另一条评论说这个答案已经过时了。真的吗？如果是这样，也许你可以更新它，这样人们就不会感到困惑。

tldr; HTTP / 1.1和HTTP / 2标头都不区分大小写。

根据RFC 7230(HTTP / 1.1)：

Each header field consists of a case-insensitive field name

followed by a colon (":"), optional leading whitespace, the field

value, and optional trailing whitespace.

https://tools.ietf.org/html/rfc7230#section-3.2

此外，RFC 7540(HTTP / 2)：

Just as in HTTP/1.x, header field names are strings of ASCII

characters that are compared in a case-insensitive fashion.

https://tools.ietf.org/html/rfc7540#section-8.1.2

只是澄清：字段名称不区分大小写;字段值可以区分大小写，具体取决于字段名称。

来自HTTP / 2 RFC的持续引用："但是，在HTTP / 2编码之前，必须将头字段名称转换为小写。包含大写头字段名称的请求或响应必须被视为格式错误(第8.1.2.6节)"

我刚刚注意到"必须转换为小写......"部分。这是为什么？ CamelCase在实践中似乎是首选的外壳(开发人员工具，流行的代码库)，那么为什么HTTP / 2会试图反对这种趋势呢？

@jimp - 因为标准是关于一致性的 - 使用camel-case可能含糊不清 - 尤其是缩写，初始化和首字母缩略词。例如 - 它是"Front-End-Https"还是"Front-End-HTTPS" -"WWW-Authenticate"或"Www-Authenticate" - 指定所有小写通过标准化字段来消除歧义。这反过来简化了全面处理标题。

header('Content-type: image/png')

没有使用PHP 5.5服务IE11，因为在图像流中显示为文本

header('Content-type: image/png')

工作，如图像中出现的图像

唯一的区别是资本'T'。

然后显然存在实现问题，因为所有头字段都应该读作不区分大小写。 Apache Bench也搞砸了。它不喜欢小写字段名称。

HTTP的RFC(如上所述)规定标题不区分大小写，但是你会发现，对于某些浏览器(我在看你，IE)，每个单词的大写最好：

Location: http://stackoverflow.com

Content-Type: text/plain

Location: http://stackoverflow.com

Content-Type: text/plain

这不是"HTTP"标准，而是另一个浏览器怪癖，我们作为开发人员，必须考虑。