operasi ajax gagal tanpa diduga
P粉511985082
2023-08-28 16:25:52
<p>我们在网站上的许多地方使用了 ajax。一个实例有时会表现得不规则，就像 ajax 调用失败一样。它仅在一个特定位置 - 所有其他位置都按预期工作。</p>
<p>发生故障时，用户会收到操作失败的错误消息。</p>
<p>我们无法重现该故障。它总是只适合我们。大多数用户没有遇到这个问题。少数确实这样做的人有时会报告说他们稍后再试一次并且成功了。</p>
<p>我们可以通过重命名ajax脚本来模拟失败。然后，当尝试操作时，ajax 调用失败，我们收到相同的错误消息。然而，我们没有任何理由相信该错误是由于无法访问 ajax 脚本引起的，尽管有可能。如果是这样的话，那么我们的其他 ajax 脚本也会出现同样的问题。</p>
<p>我们已经想出了一个解决方法。如果用户在尝试操作之前进入隐身模式，则可以避免该问题。</p>
<p>隐身模式解决方法表明它可能与 cookie 有关。因此，我们尝试以某种方式干扰 cookie，以尝试重现该问题。什么都没有成功。</p>
<p>为了帮助排除故障，我们在错误消息中添加了额外的诊断信息，但到目前为止，除了类似于“错误”的信息之外，还没有任何结果。下面是一些代码，显示了我们如何尝试获取更多信息：</p>
<pre class="brush:php;toolbar:false;">error: function (jqXHR, textStatus, errorThrown)
{
// alert('read-unread error');
ajaxError('Read-Unread', textStatus, errorThrown); // TODO comment out to suppress the error reporting
},</pre>
<p>为了完整起见，我在下面包含了完整的 JavaScript 函数。</p>
<p>建立一个简单的测试环境来演示问题效果并不好，因为它会过于简化真实环境，从而破坏了其测试价值。我们认为唯一合理的测试是模拟用户正在做的用例。不幸的是，这很复杂，因为它涉及在我们的系统上创建个人资料，尝试使用该系统与其他成员进行通信，从其他成员那里获得一些响应通信，然后尝试回复此类通信。这会重新创建用例以及发生故障的位置。不幸的是，我们再次怀疑它仍然永远不会触发我们的失败——玩具系统也会“正常工作”。</p>
<p>如果每次都发生在每个用户身上，那将是一回事，但事实并非如此。某些时候只有部分用户使用，并且仅用于我们网站上众多 ajax 使用中的一种。一旦它开始发生，至少在一段时间内该用户可以重复。</p>
<p>我的问题：</p>
<ol>
<li><p>我们如何创建一个精简版本的环境，以便我们可以让 stackoverflow 社区值得一看，而不是模拟我们网站的使用？</p>
</li>
<li><p>“隐身模式”解决方法是否可以提供任何见解来了解出现的问题？</p>
</li>
<li><p>除了诊断在大多数情况下都能正常工作的代码之外，了解其他 Ajax 故障模式也会很有帮助。举个虚构的例子，比如“某些系统太慢，ajax 超时”。</p>
</li>
</ol>
<p>[JavaScript 函数。注意：由于某种原因，我无法将函数的前几行放入代码标记中。]</p>
<pre class="brush:php;toolbar:false;">function toggleReadUnread(usertypeid, opp_user_label_short, principalid, repid, contactuid, value) {
var new_response = (value) ? 'read' : 'unread';
var prefix = '#' + contactuid;
$('#ur-read-unread-text').html(new_response);
$('#read-unread-dialog').dialog
({
show: "fade",
title: "Change to " + new_response + "?",
modal: true,
resizeable: false,
width: getDialogWidth(400, .9),
maxWidth: 400,
fluid: true,
buttons:
{
Ok: function ()
{
$(this).dialog('close');
$.ajax(
{
// async: false
type: 'POST',
url: '/ajax/set-var.php',
// url: '/ajax/tr-toggle-status.php',
data:
{
'which_function': 'read-unread',
'principalid': principalid,
'repid': repid,
'usertypeid': usertypeid,
'value': value
},
error: function (jqXHR, textStatus, errorThrown)
{
// alert(jqXHR.responseText);
ajaxError('Read-Unread', textStatus, errorThrown);
},
success: function (data, textStatus, jqXHR)
{
if (data)
{
var connector = '\', \'';
if (value)
{
$(prefix + '-unread').remove();
$('<i id="' + contactuid + '-read" class="fa fa-envelope-open tooltip" onclick="toggleReadUnread(\'' + usertypeid + connector + opp_user_label_short + connector + principalid + connector + repid + connector + contactuid + '\'' + ', false);"><span id="' + contactuid + '-read-unread-tt" class="tooltiptext">You have no unread messages from this ' + opp_user_label_short + '</span>').insertAfter(prefix + '-read-unread-placeholder');
}
else
{
$(prefix + '-read').remove();
$('<i id="' + contactuid + '-unread" class="fa fa-envelope tooltip" onclick="toggleReadUnread(\'' + usertypeid + connector + opp_user_label_short + connector + principalid + connector + repid + connector + contactuid + '\'' + ', true);"><span id="' + contactuid + '-read-unread-tt" class="tooltiptext">You have a new message from this ' + opp_user_label_short + '</span>').insertAfter(prefix + '-read-unread-placeholder');
$('.tc-' + contactuid).hide();
}
jConfirm('Success', 'Messages marked "' + new_response + '"');
}
}
})
},
Cancel: function () {
$(this).dialog('close');
}
}
})
}</pre>
<p>编辑1：</p>
<ol>
<li><p>我们仍然与用户遇到此问题。我们仍然无法在内部重现它。</p>
</li>
<li><p>隐身模式可以防止问题发生。虽然这应该是一个很好的线索，但到目前为止还没有帮助我们。它似乎指向会话和缓存问题。我们已经排除了过时的缓存问题。</p>
</li>
<li><p>它是间歇性的，仅影响少数用户。稍后甚至该用户也将不再遇到问题。再次似乎与缓存相关。</p>
</li>
<li><p>我们添加了诊断信息，有时在 ajax 错误抛出中显示“禁止”。检查这意味着它与跨域操作有关。没有进行跨域活动；所有请求都发送到我们自己的服务器。</p>
</li>
<li><p>我们向一些用户询问了他们的扩展程序。在一种情况下，他们没有安装扩展；在另一种情况下，他们只有 Chrome 的 Grammarly 扩展。我们使用该扩展进行了测试，但仍然无法重现该问题。</p>
</li>
<li><p>发生错误时，会显示一个对话框。单击该对话框上的“确定”后，其余操作应该继续进行，因为该对话框没有阻止任何内容。但是，用户报告说，如果不处于隐身模式，他们无法完成该操作。</p>
</li>
</ol>
<p>编辑2：</p>
<p>我开始研究 https-access.log。虽然大多数对 ajax 文件的访问都会返回 200，但也有返回 302 的情况。其含义是“文件已移动”。但文件并未移动，不久之后就恢复正常访问。</p>
<p>这是访问日志的摘录，显示了一系列 200 响应，其中散布着一些 302，然后恢复 200。</p>
<pre class="brush:php;toolbar:false;">108.221.39.97 - - [13/Jan/2023:10:07:52 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
108.221.39.97 - - [13/Jan/2023:10:08:34 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
108.221.39.97 - - [13/Jan/2023:10:09:56 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
73.176.158.231 - - [13/Jan/2023:10:10:21 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
74.73.226.238 - - [13/Jan/2023:10:15:07 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
184.178.239.162 - - [13/Jan/2023:10:15:18 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?reply=tr-28560-80354" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36 Edg/108.0.1462.76"
74.73.226.238 - - [13/Jan/2023:10:15:20 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
24.144.188.195 - - [13/Jan/2023:10:15:22 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
74.73.226.238 - - [13/Jan/2023:10:15:28 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
74.73.226.238 - - [13/Jan/2023:10:15:34 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
74.73.226.238 - - [13/Jan/2023:10:15:37 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
74.73.226.238 - - [13/Jan/2023:10:15:49 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
72.38.12.208 - - [13/Jan/2023:10:15:54 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?reply=tr-43850-7444" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36 Edg/108.0.1462.76"
74.73.226.238 - - [13/Jan/2023:10:16:07 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
74.73.226.238 - - [13/Jan/2023:10:16:19 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
108.221.39.97 - - [13/Jan/2023:10:17:23 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
108.221.39.97 - - [13/Jan/2023:10:17:28 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
72.38.12.208 - - [13/Jan/2023:10:17:49 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?reply=tr-43850-7444" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36 Edg/108.0.1462.76"
108.221.39.97 - - [13/Jan/2023:10:17:58 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
24.45.242.118 - - [13/Jan/2023:10:20:41 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
24.45.242.118 - - [13/Jan/2023:10:21:10 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"</pre>
<p>编辑3：</p>
<p>我们有一个候选解决方案，其灵感来自 @ibrahim 对下面 Lajos Arpad 答案的评论。简而言之，向 ajax 调用添加重试功能，如 https://forum.framework7.io/t/app-request-what-is-the-best-way-to-retry-an-ajax-request-using 所示-app-request/4759，它似乎基于What's the best way to retry an AJAX request on failure using jQuery?。</p>
<p>在我们确认此修复有效后（这将需要一些“没有报告错误”的时间），我会将其标记为“答案”，@ibramim 是否应该发布他关于重试的评论作为答案。</p>
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Simptom
Isu skrip AJAX yang anda hadapi biasanya berfungsi dengan baik, tetapi bagi sesetengah pengguna (jarang), kadangkala fail itu tidak ditemui secara ringkas.
Penyelesaian
Menggunakan mod inkognito nampaknya menyelesaikan masalah ini.
Adakah kita pasti ada penyelesaiannya?
Terdapat sedikit kemungkinan bahawa penyelesaian akan berlaku serentak tetapi tidak akan menghasilkan pemulihan AJAX. Oleh itu, dalam kes yang jarang berlaku, fail mungkin menjadi tidak tersedia untuk tempoh masa yang singkat (contohnya, terdapat skrip terputus-putus membina semula/minimum yang memadamkan sementara fail untuk memindahkan versi baharu ke tempatnya), dan pengguna Akan menghadapi situasi berikut: masalah yang anda nyatakan, bagaimanapun, apabila mereka cuba mengaksesnya melalui mod inkognito, fail telah dipulihkan, ringkasnya: mod inkognito mungkin hanya bertepatan dengan pemulihan fail, tetapi ia tidak akan menyebabkan Keadaan ini.
Untuk mengatasi masalah ini, cuba penyelesaian inkognito semasa masalah berlaku untuk melihat sama ada ia berfungsi, kemudian cuba dalam mod bukan inkognito untuk melihat sama ada ia masih tidak berfungsi (selepas halaman dimuat semula, sudah tentu). Pada separuh kedua jawapan, saya akan menganggap bahawa mod inkognito menyebabkan masalah pengguna hilang, bukan hanya bertepatan dengan ia hilang.
Sebab yang berkemungkinan
Kuki
Ada masalah dengan beberapa kuki. Sebagai contoh, kuki pengguna tamat tempoh dan tidak lagi sah, tetapi halaman mula dimuatkan semasa kuki masih sah, tetapi pelayan melemparkan ralat pemindahan fail pada permintaan untuk fail kerana ia diprogramkan untuk hanya menyampaikan permintaan ini kepada log dalam pengguna. Selain itu, /ajax/set-var.php sendiri mungkin cuba memuatkan beberapa fail yang pasti wujud dalam sesi sedia ada, tetapi sesi semasa telah dimusnahkan dan tidak lagi mempunyai akses kepada fail itu.
Caching
Cache klien mungkin mempunyai nama fail atau laluan yang tepat dan fail telah dinamakan semula atau dialihkan. Mungkin juga fail itu diminta semasa proses binaan, semasa fail sedang ditulis dan fail yang tidak lengkap telah dicache ke penyemak imbas. Dalam kes anda, ini nampaknya tidak menjadi masalah kerana anda mempunyai fail php yang telah dialihkan berdasarkan mesej ralat.
Pihak pelayan mungkin telah menyimpan beberapa maklumat untuk anda yang telah ditamatkan/tidak sah sejak itu. Sebagai contoh, jana halaman statik untuk sesi pengguna untuk mengelakkan pengulangan logik permintaan panjang yang sama.
Storan Sesi/Storan Tempatan
Ada kemungkinan bahawa beberapa nilai telah disimpan dalam
sessionStorage中，并在会话超时时丢失，但页面仍在加载，或者某些特定于会话的值存储在localStorage 中dan tidak lagi sah. Dalam kedua-dua kes permintaan itu tidak sah dan beberapa ralat dilemparkan pada bahagian pelayan menyebabkan fail tidak ditemui.Apakah maksudnya jika fail tidak ditemui?
Ini bermakna beberapa fail tidak ditemui di lokasi yang dijangkakan. Jadi untuk memperbaikinya: