当[script]文件下载失败时，如何判断原因？
我的 Web 应用程序从浏览器 javascript 向我发送诊断信息，告诉我注入的 [script] 标记无法下载关联的 .js 文件。我无法在本地重现此问题，并且没有特定的文件失败模式或浏览器类型。请求的地理位置有一个模式 - 墨西哥和巴西总是更频繁 - 所以我猜测也许那里的互联网总体上更加不稳定，而这只是导致失败的网络问题。
不过我真的很想确切地知道。有什么方法可以从浏览器 JavaScript 中确定失败是否是由于服务器返回的错误、网络错误或协议超时而发生的？我不关心该机制是否特定于浏览器，因为似乎同一问题在所有浏览器类型上都会导致错误。
My web application sends me diagnostic info from the browser javascript telling me that a [script] tag I've injected has failed to download the associated .js file. I can't reproduce this locally, and there is no particular pattern to which file fails, or what the browser type is. There is a pattern to the geo location of the requests - Mexico and Brazil are always more frequent - so I'm guessing that perhaps the internet in general is just more flaky there, and it is just network issues causing the failures.
I'd really like to know for sure, though. Is there any way to determine, from the browser javascript, whether the failure occurred because of an error returned by the server, from a network error, or from a protocol timeout? I don't care if the mechanism is browser-specific, since it seems likely that the same issue is causing the error on all browser types.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我对此表示怀疑：
我所知道的 JavaScript 中唯一能提供像您正在寻找的详细错误信息的是 Ajax。在 Ajax 中，您可以捕获超时以及服务器响应代码。
当“正常”包含失败时，您可以尝试向脚本文件发出 Ajax 请求，并分析该请求是否有错误。不过，我并不完全确定这是否有帮助：
第二个选项 - 我不知道是否有稳定的实现 - 实际上是使用 Ajax 加载脚本，并将其注入到文档中。我确信一些
病态的创造性思维已经在某个地方涉足过这个:)这将使您有机会分析任何失败（例如，进行另一个Ajax调用，发送诊断信息）。最后同样重要的是，查看服务器的错误日志是否有任何异常情况。
I doubt it: The
<script>tag may have anonerrorevent like images do, but I doubt you are going to get any detailed information from it.The only thing I know in JavaScript that gives detailed error info like what you are looking for is Ajax. In Ajax, you can catch timeouts as well as server response codes.
You could either try making an Ajax request to the script file when the "normal" inclusion fails, and analyze that request for errors. I'm not entirely sure, though, whether that'll help: It could be that the
<script>part fails, but the Ajax call loads just fine, because of the infrequent nature of the failures.The second option - and I don't know whether there is a stable implementation for this - is actually loading the script using Ajax, and injecting it into the document. I'm sure some
sickcreative mind has dabbled with this already somewhere :) This would give you the opportunity to analyze any failures (e.g. make another Ajax call, sending diagnostic information).Last not least, take a look into your server's error logs for any unusual occurrences.
首先，作为 ISP 行业的资深人士，我可以告诉您，美国南部的通信基础设施迅速恶化；只需考虑一下，它主要是拥有古老的基于铜线的长途电话网络的第三世界国家。
使用服务器日志来检测这些错误！您不需要向客户端（浏览器）询问您应该已经知道答案的问题。
由于网络错误相当广泛（例如协议超时是网络错误），我将解决这个问题，不，除非您使用某些 AJAX，否则无法调试这些错误。 jQuery 有一个 jQuery.getScript() 专门用于此任务，但它可能不会为您提供所需的选项，因此您需要采用 jQuery.getScript() 的 jQuery.ajax() 示例实现，然后实现 error() 方法，您可以在其中查看 XHR 以查看失败原因曾是。当然，所有这一切都不需要 jQuery，它只是让事情变得更容易。
First off, as a veteran of the ISP industry, I can tell you that South of the USA the communications infrastructure rapidly deteriorates; just consider that it's mostly 3rd-world countries with ancient copper-based longhaul telephony networks.
Use server logs to detect these! You shouldn't need to ask the client (browser) something which you should already know the answer to.
Since a network error is pretty broad (e.g. a protocol timeout is a network error), I'll address that, and no, there is no way to debug these unless you use some AJAX. jQuery has a jQuery.getScript() specifically for this task, but it likely won't give you the options that you need, so you'll need to take their jQuery.ajax() example implementation of jQuery.getScript() and then implement the error() method where you can peek into the XHR to see what the failure reason was. Of course jQuery isn't required for all of this, it just makes it much easier.
The
<script>tag hasonerrorbut as Pekka said before it may not provide any useful feedback. Here a code snippet just in case its something you'd like to explore further: