你有没有注意到流浪命来您的网页没有参数？

Question

我们有一个网应用程序，通过参数在url沿线的这一点：

www.example.com/ViewCustomer?customer=3945

合理的经常,我们会看到试图访问只是:

www.example.com/ViewCustomer

或系统日志，这为无效和回送一个"错误已经发生，联系支持的跟踪号码XXX"类页。

我们的记录包括会议的信息，使它实际上是某人登录在一个有效的会议，这意味着他们成功登录用户名和密码。

这可能是他们刚才输入到该地址栏，但它似乎经常发生。另一个替代方案是，我们有一个错误中我们的代码,但是我们已经进行了调查，有时只有一点，它显然是确定。我们从来没有一个用户抱怨什么不工作而导致这一点。一切都在SSL。

有任何人经历过这个？做一些浏览器发送这些各种各样的狡猾的请求偶尔?

编辑：我们的日志显示这样的：

 user-agent = Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)

Answer 1

我现在认为这实际上是一个tomcat bug getParameter（）在POST失败使用transfer-encoding：chunked 。

Answer 2

做你的记录包括引用的信息吗？如果有任何信息，那么它可有助于查明错误。如果没有，可能指示一个"编辑的网址"的尝试。(我不知道有多少SSL会改变任何此，当然.)

有时浏览器 预取的链接 但我不知道他们是否会摆脱该参数-并且它似乎是不可能的，他们愿意为我这个HTTPS。

你有一个模式作为其浏览器正在被用于这些请求？

Answer 3

我已经看到了我们正在支持的Web应用程序 - 对于已经登录的用户来说，这是一个明显的GET请求，破坏了服务器端状态并导致后续合法POST请求出错。

因为在我们的例子中，URL使用URL重写将sessionid附加到URL，所以GET有时也会有旧的sessionid。

在导致解决此问题的特定日志文件中，这些迷路请求的代理字符串与同一会话中的其余代理字符串不同（尽管有效）。

我确信，而不是浏览器本身，它是一些插件/扩展。代理可能会这样做甚至是恶意软件。

我们通过禁止对相关URI的GET请求来克服这个特殊问题。

然而，现在我正处理一个类似的问题，其中POST请求突然出现在它不应该的地方，唯一的区别在于“接受”。报头中。

Answer 4

检查日志中的代理字符串，看看这些请求是否由搜索引擎蜘蛛发出。

Answer 5

我知道我有时会删除参数只是为了检查那里有什么。我相信我不是唯一一个。

Answer 6

某些恶意抓取工具会将用户代理更改为浏览器的用户代理和抓取页面。这也可能是这种情况。

此外，大多数抓取工具都会尝试将其他一些值替换为查询参数来获取未链接的页面。