Question

Chrome和Microsoft IE正在中止POST响应，但在Firefox中工作正常。当我通过Fiddler进行测试时，我注意到Chrome / IE中的POST标头不包含Cache-Control: max-age=0和Origin: ...，但在其他方面相同。

在Chrome中，当我按下“提交”按钮时，POST将发送到服务器，进行处理，然后客户端中止响应。经过几次转发后，客户最终接受了响应；但是服务器已经处理了请求，因此导致重复信息。在Firefox上永远不会发生这种情况，它只会始终接受第一个响应。

似乎只有在请求很大时（即：包含许多要处理的字段）才会发生，这使我认为这与服务器处理请求所花费的时间有关（在Firefox的请求显示大约需要9秒钟。

Firefox中是否有某些东西会使它等待更长的时间？反之亦然，IE / Chrome中的某些内容可能会导致其过早终止？

这可能不相关，但这是Perl Mason网站。页面中具有正在提交的表单的响应标题：

HTTP/1.1 200 OK
Date: Tue, 07 Aug 2018 19:08:57 GMT
Server: Apache
Set-Cookie: ...; path=/
Set-Cookie: TUSKMasonCookie=...; path=/
Expires: Mon, 1 Jan 1990 05:00:00 GMT
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0, max-age=0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

Answer 1

原来是负责重新发布的页面上的Javascript。递归调用其自身功能的setTimeout()仍在继续设置，即使表单数据已在方法中发布。

在Chrome / IE / Edge中，表单提交将被过帐，并且该函数将继续设置另一个自身超时。随后的调用将再次POST并中止等待原始连接的连接。

尽管它也会继续设置和调用该功能，但Firefox不会重新发布。

解决方法是添加一个标记来跟踪POST的提交时间和设置时间，以停止超时周期：

function countdown(secs, starttime) {
    var d = new Date();
    if (!starttime) {
        starttime = d.getTime() / 1000;
    }
    var nowtime = d.getTime() / 1000;
    var timeleft = (starttime + secs) - nowtime;
    timeleft = Math.max(0, timeleft);

    var isposted = false; // <-- Added as fix
    if (timeleft == 0) {
        isposted = true; // <-- Added as fix
        alert("Time is up. Click OK.");
        var frm = document.getElementById("frm");
        frm.submit();
    }

    if (!isposted) { // <-- Added as fix
        timeout = setTimeout(["countdown(", secs, ", ", starttime, ")"].join(""), 1000);
    }
}

Chrome / IE中止POST响应

1 个答案: