Summary

  • RFC 1866 gave HTML authors a shared way to collect name/value input and send it to a service through a declared action and method.
  • The browser could construct a request, but HTML did not determine the service’s decision or prove that a requested effect occurred.

The page stopped being only a destination

A hyperlink gives a reader a route to another resource. A form adds a different possibility: the reader changes values in a document and asks a remote service to process them. HTML 2.0, published as RFC 1866 in November 1995, defined a form as a template for a data set plus a method and an action URI. Its data set was a sequence of name/value pairs. The browser collected what a person entered or selected; the action named where to send it; the method selected how.

That definition sounds ordinary now. At the time, it marked a practical step from browsing documents toward using network services through the same browser. Search, questionnaire, subscription, or reservation could sit in a page without a purpose-built client for every site. The standard described a common browser-to-service envelope, not every service behind it.

The 1994 record shows the model taking shape. On 11 July, Paul Burchard sent Daniel Connolly a revised FORM specification. It defined an action URL, method, encoding type, and name/value pairs; HTTP was the access protocol the proposed standard would require. GET was the default, while POST would suit many applications. Ten days later Connolly described HTML 2.0 as in final review and pointed to an interactive validator: users could enter HTML and receive the server’s parse results against the proposed DTD. This proves a specific use of browser input during review, not how common forms were.

IETF minutes later that month list forms among the technical subjects in standardization.

RFC 1866 formalized features already in informal use and recommended Level 2 user agents support form entry and submission. That wording set an expectation; it did not prove every browser implemented every control or make server applications portable. It standardized the browser-side exchange and request construction.

With GET, a browser encoded form data into the action URI and followed it much as it would a link. RFC 1866 recommended GET for idempotent processing: repeating the request should not create a lasting observable change. Search was its example. The URI could be saved or shared. The RFC warned that long URIs could expose defects in historical servers and said GET should not trigger lasting side effects. When submission changed a database or subscribed someone, POST was recommended. POST placed encoded name/value data in the request body; the browser displayed the response as after GET.

Neither method decided what the server would do. GET’s no-side-effect expectation depended on the service honoring it. POST carried data for processing but did not guarantee a transaction, receipt, or particular result. The server remained the control point for validation and effect.

The base model could not send a local file as an ordinary form field. RFC 1867, published in the same month, proposed INPUT TYPE=FILE, ACCEPT, and multipart/form-data for uploads. It was explicitly Experimental, not an Internet Standard. Each new capability had its own status and implementation path.

Forms did not create Web applications by themselves. HTTP already had methods, servers already processed requests, and early browsers differed. The bounded change was that HTML gave authors a declarative way to put user-controlled values in a browser request and implementers a shared rule for forming it. The page’s question, browser transmission, and service decision remained separate.

Sources