为什么HTML表单上没有PUT和DELETE方法？

HTML4 / XHTML1仅允许以表格形式进行GET和POST，现在看来HTML5会做同样的事情。有提议将这两个添加，但似乎并没有获得吸引力。在HTML5规范草案中不包含PUT和DELETE的技术或政治原因是什么？

这是一个有趣的问题。这里的其他答案都是推测性的，在某些情况下完全不正确。实际上，我没有做任何调查，而是进行了一些研究，发现了讨论删除和放置为什么不属于HTML5表单标准的原始资料。

事实证明，这些方法已包含在多个HTML5早期草稿（！）中，但后来在后续草稿中被删除。Mozilla实际上也在Firefox beta中实现了这一点。

从草案中删除这些方法的理由是什么？W3C在错误报告10671中讨论了此主题。Mike Amundsen赞成这种支持：

对于使用XmlHttpRequest对象的现代Web浏览器，直接执行PUT和DELETE来修改原始服务器上的资源。对于未脚本化的浏览器交互，这并不是那么简单。[...]

经常需要这种模式，因此几个常用的Web框架/库创建了“内置”解决方法。[...]

其他注意事项：

• 使用POST作为隧道而不是PUT / DELETE会导致缓存不匹配（例如POST响应是可缓存的，PUT响应不是（6），DELETE响应不是（7））
• 使用非幂等方法（POST）执行幂等操作（PUT / DELETE）会使由于网络故障而导致的恢复复杂化（例如，“可以安全地重复此操作吗？”）。
• [...]

值得阅读他的整个帖子。

汤姆·沃洛德（Tom Wardrop）也提出了有趣的观点：

HTML与HTTP有着千丝万缕的联系。HTML是HTTP的人机界面。因此，自动质疑为什么HTML不支持HTTP规范中的所有相关方法。为什么可以机器放置和删除资源，而人类却不能？[...]

矛盾的是，尽管HTML竭尽全力确保语义标记，但迄今为止，它并没有做出任何努力来确保语义HTTP请求。

该错误最终由伊恩·希克森（Ian Hickson）修复为“无法修复”，其依据如下：

将PUT作为一种表单方法毫无意义，您不希望将PUT放置为表单有效内容。DELETE仅在没有有效负载的情况下才有意义，因此对于表单也没有太大意义。

但是，这还不是故事的结局！该问题已在W3C错误跟踪器中关闭，并升级为HTML工作组问题跟踪器：

https://www.w3.org/html/wg/tracker/issues/195

在这一点上，似乎似乎不支持这些方法的主要原因仅仅是没有人花时间为它编写全面的规范。

GET和POST具有与内容无关的明确理由。GET是一种可以安全重复和缓存的方式检索URL的内容。POST以一种不安全的方式进行重复，推测性执行或缓存的方式。

对于PUT或DELETE没有类似的理由。它们都完全由POST覆盖。创建或销毁资源是不安全的重复操作，也不可靠地执行推测性操作，因此不应进行缓存。它们不需要其他特殊的语义。

因此，基本上没有任何好处。

由于Bug 10671考虑添加对PUT和DELETE的支持作为表单方法，因此在2010年提出了此问题。

对于此“功能”有一些适度的回推，并且有些笨拙，但最终在工作组错误跟踪程序上这被升级为两个问题：

• ISSUE-195：增强从表单生成HTTP请求
• ISSUE-196：定义用户代理http响应处理行为

ISSUE-196问题导致共识决定，不对规范进行任何更改，因为HTML规范当前不限制对POST请求的响应的处理方式。我认为，在尝试协调常用的POST重定向模式以及ReSTful服务器通常如何以短消息提供2xx响应而不是有用的东西在浏览器中呈现时，会引发此特定问题。

ISSUE-195问题已提交给主席。卡梅隆·琼斯（Cameron Jones）于2012年1月18日加紧志愿服务，撰写了一份变更建议，并于2014年5月29日提交成为第一份工作草案。该草案将通过W3C建议流程。

运气好的话，这将很快成为W3C的建议并由浏览器供应商实施，并且将是移除阻止程序以产生统一，语义和浏览器友好的ReSTful服务的一大进步。我认为这将引发服务模式的有趣变化。乔恩·摩尔（Jon Moore）有个很好的演讲-值得一看的超媒体API，这引起了我的兴趣，但在第一个障碍（这个障碍）上落下了脚步。

我的理解是，浏览器发送PUT或DELETE后不知道该怎么办。POST通常会重定向到适当的页面，但PUT和DELETE通常不会。这使它们适合通过ajax或本机程序进行调用，但不适用于Web浏览器表单。

我现在不能阻止它，但是我记得当他们讨论此内容时，阅读了其中一个html5邮件列表。

历史

我认为值得一提的是RFC1866（第8.1节）中html表单的首次出现。这里的method属性定义如下：

METHOD
        selects a method of accessing the action URI. The set of
        applicable methods is a function of the scheme of the
        action URI of the form. See 8.2.2, "Query Forms:
        METHOD=GET" and 8.2.3, "Forms with Side-Effects:
        METHOD=POST".

有关更多说明，请参见第8.2.2 节-GET和第8.2.3节-POST。

请记住，HTML 2.0（1995年11月）是在 HTTP 1.0（1996年5月）之前指定的。因此，每个人仅将HTTP与GET（从HTTP 0.9开始）或扩展名POST一起使用。但是只有少数Web服务器支持PUT和DELETE（如HTTP 1.0附录中所述）。

思想

如果您考虑一下Berners-Lee语义网的发展是如何发展的，那么显然它已经从实际问题变成了一般概念。首先，他想共享文档。因此，他需要加价。然后，他想在数据库中查询内容，因此他需要表格。然后，他想将新数据放入数据库。因此，他在GET和POST中使用了表格。之后，他可能意识到您可以对远程数据执行所有CRUD操作，因此对HTTP进行了扩展，但从未扩展HTML，因为为时已晚（只有少数服务器支持新的CRUD操作）。

只是引发了一个疯狂的猜测，但这可能是因为HTTP在最佳情况下在访问控制方面并不是很出色，而且每个人需要的最后一件事是恶意URL危害安全性差的网站和/或应用程序的更多方法。

除了从服务器下载到客户端以外，HTTP并不是用于文件传输的好协议。使用FTP-或使用SFTP更好。

获取和发布是传输请求数据的格式。

我想您正在询问将表单提交到RESTFUL服务中的问题。但是，更改http请求标准以假设http请求的目的没有意义。有关请求填充目的的信息最好在输入字段中处理。

具有地址以及获取和发送信息可以使服务器正确解释请求及其输入值。从那里，输入值使您可以向服务器发出开放式请求，并根据需要进行操作。例如，您可以有一个值为“ put”和“ delete”的字段