ASP.NET 和 400 错误请求错误
有时，对于在 ASP.NET 上编写的不同网站，我会收到 400 Bad Request 错误。
我知道的唯一解决方案是清理该网站的 cookie。看来问题的原因是 _utmz 和 _utma cookie，它们属于 Google Analytics。该问题在 Mozilla FireFox 中很常见，有时在 Ghrome 和 Safari 上出现，但从不在 IE 中出现。此错误是偶然发生的。
我发现了什么：
来自 ASP.Net 团队的 Stefan： http://forums.asp.net/p/1431148/3221542.aspx
在当前版本的 ASP.NET URL 中 包含冒号等字符 字符将被拒绝作为 潜在的安全威胁。这 造成这种情况的历史原因是 底层NTFS文件系统支持 备用资源流可以是 使用类似名称访问 “yourfile.txt：hiddendata.txt”。 阻止 URL 中的冒号字符 防止写得不好的应用程序 意外地与 备用资源流。
电流也有限制 传入 URL 的 ASP.NET 版本 需要映射到NTFS文件系统 为了确定管理的 配置数据。
在 ASP.NET 4 中，这些限制可能是 可选择删除。然而这些 更改在 Beta 2 版本中 ASP.NET 4 - 它们不在 Beta 1 中。我们 尝试了前面列出的网址 此论坛帖子并确认 与我们内部构建的 ASP.NET 4 你可以使用这种风格的 Url 和 处理它没有任何 400 错误。
ASP.NET 运行时、FireFox 的 cookie 管理过程或 Google Analytics 代码是否有问题？你知道哪些问题的解决方案？
Sometimes I get 400 Bad Request error for different websites written on ASP.NET.
The only solution I know is to clean up cookies for that site. Seems like that the cause of problem is _utmz and _utma cookies, which belong to Google Analytics. The problem is occurs in common cases in Mozilla FireFox, sometimes on Ghrome and Safari and never in IE. This error occurs accidentally.
What I found:
From Stefan on the ASP.Net team:
http://forums.asp.net/p/1431148/3221542.aspxIn current versions of ASP.NET Urls
containing characters like the colon
character will be rejected as a
potential security threat. The
historical reason for this is that the
underlying NTFS file system supports
alternate resource streams that can be
accessed with names like
"yourfile.txt:hiddendata.txt".
Blocking the colon character from Urls
prevents poorly written applications
from accidentally working with
alternate resource streams.There is also a limitation in current
versions of ASP.NET that incoming Urls
need to map to the NTFS file system
for purposes of determining managed
configuration data.In ASP.NET 4 these limitations can be
optionally removed. However these
changes are in the Beta 2 version of
ASP.NET 4 - they are not in Beta 1. We
tried out the Url listed earlier in
this forum post and confirmed that
with our internal builds of ASP.NET 4
you can use that style of Url and
process it without any 400 error.
Is is a problem with ASP.NET runtime, cookie managment process of FireFox or Google Analytics code? What problem solutions do you know?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
问题在于 Firefox 处理 cookie 中特殊字符的方式。它与asp.net 没有任何关系，无论您使用什么语言，您都会遇到错误。
该问题似乎最常发生在 Google Analytics 活动来源上。您应该简单地尝试将这些值保留为字母字符。
我个人必须解决人们在查询字符串中使用撇号和 mDash 的问题。因此，我告诉人们要避免使用连字符和撇号。如果您不是包含它们的人，则无法确定它们没有复制浏览器无法处理的特殊字符。
本论坛建议清除400页面上的不良cookie，以便他们可以正常访问该网站。
已经有另一个问题存在同样的问题堆栈溢出。
在设置活动源等之前，您需要确保不包含任何特殊字符。通过 CMS 时事通讯等动态创建的源如果未进行积极格式化，则可能包含不良字符。我们遇到了一些麻烦，人们将 MSOffice 字符粘贴到标题和链接中，这会破坏 cookie 并停止提供页面。
除了确保不会向 GA 发送错误数据并导致 cookie 损坏之外，没有其他解决方案。
The issue is with the way that firefox handles special characters in cookies. It doesn't have anything to do with asp.net, you will have the error whatever language you are using.
The issue seems to occur most often with Google Analytics campaign sources. You should simply try to keep the values in these to alpha characters.
I have personally had to fix issues where people used an apostrophe and an mDash in their query strings. As a result I tell people to just avoid hyphens and apostrophes all together. If you aren't the one including them, you can't be sure they didn't copy a special character the browser can't handle.
This forum has a suggestion for clearing the bad cookies on the 400 page so that they can access the site properly.
There is already another question with the same problem on stackoverflow.
You need to make sure that you are not including any special characters before you set the campaign sources etc. Sources that are created dynamically through CMS newsletters etc. can include bad characters if they are not formatted aggressively. We have had trouble with people pasting MSOffice characters into titles and links which break cookies and stop the page from being served.
There is no solution to the problem other than making sure that you aren't sending bad data to GA and causing cookies to be corrupted.