Кратко

  • RFC 1866 дала авторам HTML общий способ собирать пары «имя—значение» и отправлять их службе через заданные действие и метод.
  • Браузер мог сформировать запрос, но HTML не определял решение службы и не подтверждал, что требуемый эффект наступил.

Страница стала не только местом назначения

Ссылка ведёт к другому ресурсу. Форма позволяет изменить значения в документе и попросить удалённую службу обработать их. HTML 2.0, опубликованный как RFC 1866 в ноябре 1995 года, определил форму как шаблон набора данных с методом и URI действия. Данные были парами «имя—значение»: браузер собирал ввод, действие задавало адрес, метод — способ отправки.

Тогда это стало практическим шагом от чтения документов к использованию сетевых служб в том же браузере. Поиск, анкета, подписка или бронирование могли появиться на странице без клиента для каждого сайта. Стандарт описывал общий формат между браузером и службой, а не всю её внутреннюю логику.

11 июля 1994 года Пол Бёрчард отправил Дэниелу Коннолли пересмотренную спецификацию FORM: URL действия, метод, кодирование и пары «имя—значение». Обязательным протоколом доступа предлагался HTTP. GET был методом по умолчанию, POST подходил многим приложениям. Через десять дней Коннолли сообщил о финальном рассмотрении HTML 2.0 и интерактивном валидаторе: пользователь вводил HTML, сервер возвращал разбор по предложенной DTD. Это пример во время обсуждения, а не статистика распространения. Июльские протоколы IETF также отмечают формы как тему стандартизации.

RFC 1866 формализовала функции, уже использовавшиеся неофициально, и рекомендовала агентам уровня 2 поддерживать ввод и отправку. Это ожидание соответствия, не доказательство реализации всех элементов каждым браузером и не гарантия переносимости приложений. Стандарт унифицировал браузерную часть обмена и сборку запроса.

При GET браузер кодировал данные в URI действия и переходил по ней как по ссылке. RFC рекомендовала GET для идемпотентной обработки, где повтор не оставляет постоянного наблюдаемого изменения; пример — поиск. URI можно сохранить или передать. Документ предупреждал о длинных URI и долговременных эффектах GET. Для изменения базы данных или подписки рекомендовался POST: пары помещались в тело запроса, браузер показывал ответ.

Метод не решал за сервер. GET оставался без эффекта только при соответствующем поведении службы; POST не гарантировал транзакцию, квитанцию или результат. Проверка и действие оставались у сервера. Базовая модель не отправляла локальный файл как обычное поле. RFC 1867 предложила INPUT TYPE=FILE, ACCEPT и multipart/form-data, но имела статус Experimental, а не интернет-стандарта.

Формы сами не создали веб-приложения. Изменение было уже: HTML дал авторам декларативный способ помещать пользовательские значения в запрос и общие правила его построения. Вопрос страницы, отправка браузера и решение службы оставались разными событиями.

Sources