HTTP Cookie由名称 - 值对组成,可以由服务器使用此响应进行设置:
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: name=value
Set-Cookie: name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT
来自客户端的未来请求将如下所示:
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: name=value; name2=value2
Cookie的名称是否区分大小写?
例如,如果我的服务器发送响应:
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: Aaaa=Bbbb
Set-Cookie: aAaa=bBbb
Set-Cookie: aaAa=bbBb
Set-Cookie: aaaA=bbbB
期望客户端(Chrome,FireFox,Safari,IExplorer,Opera等)使用标头Cookie: Aaaa=Bbbb; aAaa=bBbb; aaAa=bbBb; aaaA=bbbB;
发送未来请求是否合理?
注意:问题既不是特定于JSP的,也不是特定于PHP的,也不是特定于ASP的。
答案 0 :(得分:33)
Cookie名称为case- 敏感。 RFC没有明确说明,但每个case- 不敏感的比较都是明确说明的,并且没有关于cookie名称的明确声明。 Chrome和Firefox都将Cookie视为案例敏感,并将所有案例变体保留为不同的Cookie。
测试用例(PHP):
print_r($_COOKIE);
setcookie('foo', '123');
setcookie('Foo', '456');
加载脚本两次,在第二次运行时观察$_COOKIE
转储。
答案 1 :(得分:3)
底部是一个脚本,用于演示浏览器和.Net框架上的Cookie区分大小写。每次运行时,它都会插入一个名为xxxxxxxxxx的cookie,随机大写/小写。按F5刷新几次以插入几个cookie。
我在Chrome和Firefox上测试它,两者都表现出类似的行为,如下所示:
Request.Cookies["xxxxxxxxxx"].Name returns: xxxxXxXXXX
All XXXXXXXXXX Cookies:
xxxxXxXXXX
xXxxXxXXXx
XxxxxXxXXx
XXXxXxXXxX
它显示:
正如其他答案所述,新的RFC表明Cookie区分大小写,Chrome和Firefox似乎都是这样处理的。 .Net Framework可以处理区分大小写的cookie,但它确实希望对区分大小写的cookie进行处理,并且它的许多功能都以这种方式处理cookie(Cookies [],Cookies.Set()等)。这种不一致可能导致许多难以追踪的错误。
TestCookie.aspx:
<%@ Page language="c#" AutoEventWireup="false" validateRequest=false %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title id="title">Test Cookie Sensitivity</title>
</head>
<body>
<p>Request.Cookies["xxxxxxxxxx"].Name returns:
<%
HttpCookie cookie2 = Request.Cookies["xxxxxxxxxx"];
if (cookie2 == null) Response.Write("No cookie found");
else Response.Write(cookie2.Name);
%>
</p>
<h3>All XXXXXXXXXX Cookies:</h3>
<ul>
<%
foreach (string key in Request.Cookies.Keys)
if (key.ToLower() == "xxxxxxxxxx") Response.Write("<li>" + key + "</li>");
Random rand = new Random();
StringBuilder name = new StringBuilder();
for (int i = 0; i < 10; i++) {
if (rand.Next(2) == 0) name.Append('x');
else name.Append('X');
}
HttpCookie cookie = new HttpCookie(name.ToString());
cookie.HttpOnly = true;
cookie.Expires = DateTime.Now.AddMonths(1);
Response.Cookies.Add(cookie);
%>
</ul>
</body>
</html>
答案 2 :(得分:2)
似乎Cookie实际上区分大小写。这有点混乱。有趣的是,MSDN说不然:
Cookie名称不区分大小写
来源:http://msdn.microsoft.com/en-us/library/ms970178.aspx文章的底部说它©2002
所以它可能已经过时了。
此外,asp.net论坛也提出了这个问题:http://forums.asp.net/t/1170326.aspx?Are+cookie+names+case+sensitive+似乎答案是区分大小写的。
发生了什么? MSDN说不,其他技术说是。可以肯定的是,我使用ASP classic测试了这个。
hashUCASE = Request.Cookies("data")("Hash")
hashLCASE = Request.Cookies("data")("hash")
Response.Write "<p> hashUCASE = " & hashUCASE
Response.Write "<br> hashLCASE = " & hashLCASE
cookieNameUCASE = Request.Cookies("Data")
cookieNameLCASE = Request.Cookies("data")
Response.Write "<p> cookieNameUCASE = " & cookieNameUCASE
Response.Write "<br> cookieNameLCASE = " & cookieNameLCASE
Response.End
hashUCASE: EE3305C0DAADAAAA221BD5ACF6996AAA
hashLCASE: EE3305C0DAADAAAA221BD5ACF6996AAA
cookieNameUCASE: name=1&Hash=EE3305C0DAADAAAA221BD5ACF6996AAA
cookieNameLCASE: name=1&Hash=EE3305C0DAADAAAA221BD5ACF6996AAA
正如您在结果中所看到的,值&#34; Hash&#34;是用大写创建的,即使以小写形式发出请求,它也会返回相同的值,这使得它不区分大小写。在这种MS技术下,它不是。
因此,在ASP classic中使用Request.Cookies()时,它的不区分大小写,就像微软所说的那样。但等等,是不是再次区分大小写?这可能意味着是否敏感取决于向浏览器发出请求的服务器端技术,这可能会使cookie名称正常化以发出请求,从而使其不区分大小写。但那是我们必须测试以验证的其他内容。
我的建议是使用您正在使用的任何技术进行测试,并在您的代码库中建立标准,与您的团队达成协议。即如果您要使用cookie,请确定在您要在代码中使用它时,是否始终以小写或大写形式写入。这样就不会出现任何大小写敏感问题,因为在你的代码中,它总是以相同的大小写声明。
只要您使用Cookie名称保留约定,就不会出现区分大小写的问题。
答案 3 :(得分:1)
根据RFC 2109 - HTTP State Management Mechanism Cookie名称,属性名称不区分大小写:
4.1语法:常规
两个状态管理标头Set-Cookie和Cookie很常见 涉及属性 - 值对的句法属性。下列 语法使用符号和标记DIGIT(十进制数字)和 令牌(非正式地,一系列非特殊的非白色空间 字符)来自HTTP / 1.1规范[RFC 2068]来描述 他们的语法。
av-pairs = av-pair *(";" av-pair)
av-pair = attr ["=" value] ; optional value
attr = token
value = word
word = token | quoted-string
属性(名称)(attr)不区分大小写。空格是 令牌之间允许。注意,虽然上面的语法 description将值显示为可选值,大多数attrs需要它们。
答案 4 :(得分:0)
根据MSDN,Cookie名称不区分大小写。但是,我不确定这是否只是ASPX / IIS特定的实现。我相信这取决于网络服务器和语言。
如果您发送名为“UserID”的cookie,浏览器将确保将其作为“UserID”发回,而不是“userid”。