Html 在现代浏览器中，表单发布行为发生了变化吗？（或浏览器如何处理双击）

背景：我们正在编写注册/支付页面，我们的理念是首先在服务器端编写所有验证和错误检查代码，然后作为第二步添加客户端验证（un-jQuery）

我们想在服务器端禁用双击，所以我们编写了一些锁定、线程安全的代码来处理同时发布/竞争条件。当我们尝试测试这一点时，我们意识到我们不能导致同时发生赛后或比赛情况

我认为（无论如何，在旧浏览器中）双击提交按钮的工作方式如下：

• 用户双击提交按钮

• 浏览器在第一次单击时发送帖子
• 在第二次单击时，浏览器取消/忽略初始post，并启动第二次post（在第一次post返回响应之前）
• 浏览器等待第二个post返回，忽略初始post响应

我认为从服务器端看，它是这样的：服务器同时获得两个post请求，执行并响应它们（不知道没有人在监听第一个响应）

根据我们的测试（FireFox 3.0，IE 8.0），实际情况如下：

• 用户双击提交按钮

• 浏览器会在第一次单击时发送帖子
• 浏览器排队等待第二次单击，但等待第一次单击的响应
• 从第一次单击返回响应（是否忽略响应？）
• 浏览器会在第二次单击时发送帖子

所以从服务器端：服务器接收一个post，并执行和响应它。然后，服务器接收第二个请求，并对其执行和响应

我的问题是，这是否一直都是这样的（而且我正在失去理智）？或者这是现代浏览器中的一项新功能，可以防止同时向服务器发送帖子？

---

似乎对于服务器端的双击预防，我们不必担心同时发布或竞争条件。只需要担心排队的帖子。

只要请求处于连接或发送阶段，在第一次提交时单击submit就会取消请求，在服务器“不知道”的情况下启动一个新的请求。

这可能是一个愚蠢的响应，但为什么不在单击时用javascript禁用submit按钮呢，所以你不必担心多次点击。我通常在我制作的大多数表单上都这样做，这似乎解决了问题

---

您已经说过您正在使用javascript，所以这不是问题所在，对吗？

您需要处理的类似情况（javascript禁用提交按钮解决方案没有涵盖）是，用户单击提交，服务器处理请求，但在处理用户的internet连接时，服务器会关闭（也许他们在一列驶入隧道的火车上）

当火车驶出隧道时，用户不知道他们的交易是否成功——他们按下了按钮，但页面上没有任何变化（或者他们得到了一个“重试”页面）。他们要做的自然事情是再次单击提交（或“重试”按钮）

处理此情况的最佳方法是在表单中包含唯一的事务id（在隐藏字段中）。随机生成此id，当事务成功处理时，将其存储在数据库中已完成事务的列表中

然后，当您收到帖子时，检查此事务是否已被查看-如果已被查看，请直接跳到状态页面。大致如下：

BEGIN TRANSACTION

SELECT *
FROM completedTransactions
WHERE userId = ... AND transactionId = ...

<if we got a result - display results of previous transaction>

<otherwise - process the request as normal>

INSERT INTO completedTransactions (userId, transactionId)
VALUES (....)

END TRANSACTION

开始交易
挑选*
从已完成的事务中删除
其中userId=…和transactionId=。。。
插入到completedTransactions（用户ID、transactionId）
值（…）
结束交易

这样做的好处是（如果你有一个适当支持交易的数据库——既然你在处理付款，我希望你能做到！）你不需要做任何类型的线程或锁定——一切“正常”

（尽管要小心-如果存在并发问题，某些数据库系统可以任意中止事务-但这种（罕见的）情况可以使用重试循环轻松处理…）

---

至于测试浏览器的双击：如果你在两个“提交”之间按“停止”按钮，会有什么区别吗点击？

+1非常清楚的问题，看到用户操作图很有趣。我不确定答案，但通常情况下，人们更倾向于一次点击而不是两次点击——双击是较旧的、以桌面为中心的模式。更新：IE8的行为似乎有所不同（允许同时向服务器发送多个帖子）和FF/Chrome（排队等待多次点击）。我将在我们进行更多测试的同时发布更多的结果。IE8似乎是这样，但Chrome或FireFox却不是这样。策略是首先在服务器端进行所有验证/检查。一旦验证/检查起作用，我们将实施客户端检查。这确保即使有人禁用JavaScript，或出现客户端错误，也不会我同意，客户端解决方案几乎微不足道，但我们希望确保我们的应用程序在服务器端也是坚如磐石。