摘要

  • RFC 1866 为 HTML 作者提供了统一方式：收集名称—值输入，并按声明的动作和方法发送给服务。
  • 浏览器可以构造请求，但 HTML 不决定服务如何处理，也不能证明请求的效果已经发生。

页面不再只是目的地

超链接指向另一项资源。表单允许用户修改页面中的值，再请远端服务处理。1995年11月发布的HTML 2.0（RFC 1866）把表单定义为数据模板，并附有方法和动作URI。数据集是一串名称—值对：浏览器收集输入或选择，动作指定目的地，方法决定传送方式。

这在当时是从浏览文档走向使用网络服务的一步。搜索、问卷、订阅申请或预约都能放在网页里，不必为每个站点另做客户端。标准描述了浏览器与服务间的共同请求形式，却没有规定服务背后的全部逻辑。

档案显示，模型在1994年仍在形成。7月11日，Paul Burchard把修订后的FORM规范发给Daniel Connolly，定义动作URL、方法、编码和名称—值对，并说明HTTP是提案要求支持的访问协议。默认GET，许多应用适合POST。十天后，Connolly称HTML 2.0进入最终审阅，并提到交互式验证服务：用户输入HTML，服务器按拟议DTD解析并返回结果。这是审阅期间的具体用途，不代表普及率。7月IETF会议纪要也把表单列入标准化技术议题。

RFC 1866正式化了此前非正式使用的功能，并建议Level 2用户代理支持输入和提交。这是符合性预期，不证明所有浏览器实现了全部控件，也不让服务端行为可移植。标准化的是浏览器侧交换形式和请求构造规则。

使用GET时，浏览器把编码后的表单值附加到动作URI，像跟随链接那样访问。RFC建议对幂等处理使用GET，也就是重复请求不留下持久、可观察的变化；搜索是它的例子。URI可以收藏或分享。RFC还提醒，过长URI会让部分旧服务器出错，GET不应触发持久副作用。若要改数据库或创建订阅，应使用POST。POST把编码数据放在请求正文，浏览器随后显示响应。

两种方法都不替服务器决定行为。GET无副作用要看服务是否遵守；POST能携带待处理数据，却不保证交易、回执或特定结果。验证与效果仍由服务器控制。基础模型也不能把本地文件当普通字段发送。同月发布的RFC 1867提出INPUT TYPE=FILE、ACCEPT和用于上传的multipart/form-data，明确标为Experimental而非互联网标准。

表单并未独自创造Web应用。HTTP已有方法，服务器早已处理请求，浏览器功能各不相同。准确的变化是HTML提供声明式方式，把用户控制的值放进浏览器请求，并给实现者共同的构造规则。页面提问、浏览器发送、服务决定仍是三件事。

Sources