关于 cookie 和路径的 RFC 问题
我试图在用户登录时设置一个仅限于特定路径（例如 /foo）的会话 cookie。复杂之处在于登录页面位于 / 上，但请求立即重定向到 /foo/something。像这样的东西：
请求：
POST / HTTP/1.1
username=foo&password=bar
响应：
HTTP/1.0 302 Found
Location: http://example.com/foo/home
Set-Cookie: session=whatever; path=/foo
但是，我可以找到 RFC 的相关位（rfc2109< /a> 和 rfc2965) 这样说：
为了防止可能的安全或隐私侵犯，用户代理 如果满足以下任一条件，则拒绝 cookie（不应存储其信息）： 以下正确的是：
- Path 属性的值不是请求的前缀 - URI。
...
上面描述的 cookie 设置过程似乎可以工作，但据我所知，RFC 说不应该。
我想在生产系统中使用它，但如果我以后会遇到可怕的浏览器不兼容问题，我真的不想这样做。
我是否误读了 RFC？
提前致谢！
I'm trying to set a session cookie restricted to a particular path (let's say /foo) when a user logs in. The complication being that the login page is on /, but the request immediately redirects to /foo/something. Something like this:
Request:
POST / HTTP/1.1
username=foo&password=bar
Response:
HTTP/1.0 302 Found
Location: http://example.com/foo/home
Set-Cookie: session=whatever; path=/foo
However, the relevant bits of the RFCs I could find (rfc2109 and rfc2965) say this:
To prevent possible security or privacy violations, a user agent
rejects a cookie (shall not store its information) if any of the
following is true:
- The value for the Path attribute is not a prefix of the request-
URI....
The cookie-setting process described above seems to work okay, but as far as I can tell the RFCs are saying it shouldn't.
I'd like to use this in a production system, but I really don't want to do that if I'm going to face horrible browser incompatibility problems later.
Am I misreading the RFCs?
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不要关注那些 RFC；他们与现实严重背离。
目前有一个 IETF 工作组正在记录实际的 cookie 行为；他们的文件虽然只是草稿，但却是更好的原始材料。
看：
http://datatracker.ietf.org/doc/draft-ietf-httpstate -cookie/
如果您在草稿中找不到解决您问题的文本，请向工作组提出！
Don't pay any attention to those RFCs; they diverge from reality pretty badly.
There's currently an IETF WG that's documenting actual cookie behaviour; their document, while just a draft, is much better source material.
See:
http://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/
If you don't find text that addresses your question in the draft, bring it up with the Working Group!
根据你的问题，我认为你对RFC的理解是正确的。听起来您想在重定向到 '/foo/home' 后设置 cookie。我认为真正的问题是：“你如何告诉 '/foo/home' 用户已通过 '/' 正确验证em>？”
如果您必须使用 Location 标头（重定向）从 '/' 到 '/foo/home'，似乎唯一的方法是在 Location 标头的值中使用查询字符串参数。
也许需要考虑的一个设计问题是：为什么用户要针对他们将安全访问的路径之外的 URL 进行身份验证？如果唯一的安全内容位于 '/foo' 下，那么为什么不 POST 到 '/foo/login' > 而不是 '/' 进行身份验证？
Based on your question, I think your understanding of the RFC is correct. It sounds like you want to set the cookie after the redirect to '/foo/home'. I think the real question is: "How do you tell '/foo/home' that the user was authenticated correctly by '/'?"
If you must use a Location header (redirect) to get from '/' to '/foo/home', it seems the only way to do this would be to use a query string parameter in the Location header's value.
Maybe a design question to consider is: why are users authenticating against a URL outside of the path they will be accessing securely? If the only secure content is under '/foo', then why not POST to '/foo/login' instead of '/' for authentication?