Resumen

  • La RFC 1866 ofreció a quienes escribían HTML una forma común de reunir pares nombre-valor y enviarlos a un servicio mediante una acción y un método declarados.
  • El navegador podía construir la petición, pero HTML no decidía qué haría el servicio ni demostraba que se hubiera producido el efecto solicitado.

La página dejó de ser solo un destino

Un enlace ofrece una ruta hacia otro recurso. Un formulario permite cambiar valores en un documento y pedir a un servicio remoto que los procese. HTML 2.0, publicado como RFC 1866 en noviembre de 1995, definió el formulario como una plantilla de datos con método y URI de acción. Los datos eran pares nombre-valor: el navegador reunía lo escrito o seleccionado, la acción indicaba el destino y el método establecía el envío.

Hoy parece normal. Entonces fue un paso de consultar documentos a utilizar servicios de red desde el mismo navegador. Una búsqueda, encuesta, suscripción o reserva podía caber en una página sin un cliente específico para cada sitio. El estándar describía un formato común entre navegador y servicio, no toda la lógica de este.

El registro de 1994 muestra la formación del modelo. El 11 de julio, Paul Burchard envió a Daniel Connolly una revisión de FORM que definía URL de acción, método, codificación y pares nombre-valor; HTTP sería el protocolo requerido. GET era predeterminado y POST serviría para muchos usos. Diez días después, Connolly dijo que HTML 2.0 estaba en revisión final y señaló un validador interactivo: el usuario introducía HTML y el servidor devolvía el análisis conforme a la DTD propuesta. Es un ejemplo durante la revisión, no una medida de difusión. Las actas del IETF también mencionan formularios en el trabajo de normalización.

RFC 1866 formalizó funciones ya usadas informalmente y recomendó que agentes de nivel 2 admitieran entrada y envío. Es una expectativa de conformidad, no prueba de que cada navegador implementara cada control ni de que las aplicaciones fueran portables. El estándar alineó el intercambio del navegador y la construcción de la petición.

Con GET, el navegador codificaba los datos en la URI de acción y la seguía como un enlace. La RFC recomendaba GET para procesamiento idempotente: repetir la petición no debía dejar un cambio duradero observable. La búsqueda era el ejemplo, y la URI podía guardarse o compartirse. También advertía que algunos servidores antiguos manejaban mal las URI largas y que GET no debía provocar efectos duraderos.

Para alterar una base de datos o inscribir a alguien se recomendaba POST. Los pares codificados iban en el cuerpo de la petición y el navegador mostraba la respuesta. Ningún método decidía lo que haría el servidor. GET dependía del servicio para no causar efectos; POST no garantizaba transacción, recibo ni resultado concreto. Validación y efecto seguían en manos del servidor.

El modelo inicial no podía enviar un archivo local como campo normal. RFC 1867 propuso el mismo mes INPUT TYPE=FILE, ACCEPT y multipart/form-data para cargas. Era Experimental, no estándar de Internet. Cada ampliación tenía su propio estado e implementación.

Los formularios no crearon por sí solos las aplicaciones web. HTTP ya tenía métodos, los servidores procesaban peticiones y los navegadores variaban. El cambio acotado fue dar a los autores una forma declarativa de poner valores del usuario en una petición y una regla compartida para construirla. La pregunta, la transmisión y la decisión del servicio quedaron separadas.

Sources