Web 调试：跟踪 GET 源
我正在尝试修复我们丰富的 GUI Web 应用程序中长期存在的错误。它是在没有查询字符串参数的情况下异地执行 GET，导致服务器上业务层由于缺少参数而未捕获异常，并以错误页面的形式返回。
环境：jQuery（UI）+ DWR（允许Java和JS通过AJAX互相调用）+ Spring/Spring MVC
浏览器：IE8、FF3.6、Chrome 6 @ WinXP
我当前使用的工具：Chrome Inspector、Firebug、HttpFox（FF嗅探器）扩展名，对于查明错误请求很有用）
试图缩短它，我找不到执行 GET 的代码片段，可能是因为它被注册为事件（如模糊、卸载等）或者是异步事件DWR，也许吧。整个 UI 是基于 DWR (AJAX) 调用构建的，因此某处可能存在错误的调用。我尝试搜索方法名称、函数指针、在 jQuery 上注册的事件、DWR 接口调用、使用 Firebug 回溯 JS 堆栈......但没有效果。
我最后的努力是寻找一些工具，可以找到哪一段代码执行 POST/GET 或类似的东西......自从我没有想法以来，我一直在黑暗中拍摄。
所以，我想知道任何工具建议或任何可用于定位隐藏 GET 的技术。任何帮助表示赞赏。
谢谢！
I'm trying to fix a long standing bug in our rich GUI web app. It is a GET being executed out of place without query string parameters, causing uncaught exception on the business layer on the server due to missing parameters, returned as an error page.
Environment: jQuery (UI) + DWR (allow Java and JS to call each other through AJAX) + Spring/Spring MVC
Browsers: IE8, FF3.6, Chrome 6 @ WinXP
My current tools: Chrome inspector, Firebug, HttpFox (FF sniffer extension, was useful to pinpoint the bad request)
Trying to shorten it, I couldn't find which piece of code executes the GET, probably because it was registered as an event (like blur, unload, etc) or is an async event by DWR, maybe. The whole UI is build upon DWR (AJAX) calls, so there may be a wrong call somewhere. I tried searching for method names, function pointers, events registered on jQuery, DWR interface calls, tracing back the JS stack with Firebug... no good.
My last effort was searching for some tool that could locate which piece of code executes the POST/GETs or something like it... I've been shooting in the dark ever since I ran out of ideas.
So, I'd like to know any suggestion of tools or whatever technique can be used to locate a hidden GET. Any help is appreciated.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果可用，请检查您的网络服务器日志。识别错误的 GET 之一，该行还应包含引荐来源网址。
这至少应该告诉您哪个或哪些页面负责调用，这有望缩小范围。
If available, check your web server logs. Identify one of the bad GETs and that line should also include the referrer.
This should at least tell you which page or pages are responsible for the call which should hopefully narrow things down.