我在Play Framework 1.2.5中运行了一个包含多个用户的应用程序。
有时用户会在几分钟之前就为他们工作过的特定网址开始收到324错误。 （324 = Chrome中没有收到任何数据，服务器在IE8中关闭了连接）。收到此消息后，他们会继续收到错误。
我可以看到请求到达运行Play Framework的计算机（通过Wireshark），但请求似乎没有到达Play控制器。 （调试和跟踪消息作为控制器的第一步不会输出到日志）。 我已经看到两个不同控制器出现问题，可能会影响更多。
清除浏览器缓存，历史记录，重新启动客户端，重新启动Play，重新启动服务器似乎没有任何区别。
其他浏览器可以成功访问“已损坏”的网址。 “损坏的”客户端可以访问同一应用程序中的其他URL。
有人知道吗： 1）知道为什么会发生这种情况，或者看到同样的问题，或者 2）有人知道响应链中的哪个位置可能会轰炸或发送324？ 2）我如何能够更深入地追踪出现问题（例如，我可以跟踪Netty访问吗？）
我已经搜索了类似问题的解决方案，并且只能找到一些引用类似324错误的路由文件中的错误，但这些似乎都是一致且可重复的，并且与Play 2.x相关。但是，错误的路由可能导致324错误的事实意味着我想更详细地了解路由器正在为这些损坏的请求做些什么。
任何帮助非常感谢！这让我很生气！
答案 0 :(得分：2)
好的，以防万一其他人看到这个令人生气的问题......我已经找到了原因：
Netty 3.2.4-FINAL中的已知问题意味着如果请求包含8053字节或更大的cookie，它将回复324响应。这在Play Framework社区中是众所周知的（参见http://play.lighthouseapp.com/projects/57987/tickets/1618-long-cookies-with-double-quote-values-make-play-fail-before-the-request-is-handled）。 你会注意到那里的评论线索，双引号问题是固定的，但尺寸问题仍然存在。
那么，我是如何设法生成一个大的cookie？答案：JQuery Datatable。这个梦幻般的UI元素（不，真的）有一个名为'bStateSave'的设置，允许您在cookie中保存表的状态（排序，过滤等）以改善用户体验。 数据表的cookie大约为900字节。 但是，Datatables在命名此cookie时使用URL的路径部分，因此对于应用程序中的每个不同的URL路径，您都会获得一个新的cookie。 现在只需添加一个RESTful样式的URL，例如/ item / show / 34（其中34是一个对象id），并且hey-presto，为你查看的每个项目提供一个900字节的cookie。这很快就达到了8K的限制。
覆盖数据表状态cookie的命名并不简单，但它非常简单。
首先，将以下配置添加到数据表
"bStateSave": true,
"fnStateSave": function(oSettings, oData) { save_dt_view(oSettings, oData); },
"fnStateLoad": function(oSettings) { return load_dt_view(oSettings); },
然后使用您自己的不太精确的cookie名称提供将存储和检索状态的javascript函数：
function save_dt_view (oSettings, oData) {
$.cookie('DataTables_myCookie', JSON.stringify(oData));
}
function load_dt_view (oSettings) {
return JSON.parse( $.cookie('DataTables_myCookie') );
}
感谢bennybenben在this帖子中找到我所蚕食的代码示例。