В современном интернете формы являются одной из важнейших и наиболее часто используемых технологий для взаимодействия пользователей с веб-сайтами и приложениями. Заполнение форм сопровождает регистрацию, авторизацию, отправку сообщений, приобретение товаров и многое другое. Несмотря на развитие самого веб-протокола HTTP и создание уже трех его основных версий, форматы обработки и передачи данных из форм остались практически неизменными и представляют собой источник множества проблем и неудобств для разработчиков и пользователей. История HTTP и важность форм связаны друг с другом уже не одно десятилетие. Первая версия протокола HTTP была разработана в начале 1990-х годов, и именно тогда появились основные способы передачи данных из форм, такие как application/x-www-form-urlencoded и multipart/form-data.
Однако за прошедшие с тех пор почти тридцать лет стандарты стали скорее обременительной реликвией прошлого, нежели современным решением, отвечающим потребностям веба будущего. Одной из ключевых проблем современных форм является отсутствие единой и чётко прописанной спецификации. Формат application/x-www-form-urlencoded, который чаще всего используется для простых форм, фактически опирается на правила кодирования URL, описанные в RFC 3986. Это приводит к неодинаковому поведению различных браузеров и серверов при обработке одних и тех же данных, особенно если речь идет о специальных символах или нестандартных значениях, таких как эмодзи или многоязычные символы. При этом специфицированность данного формата была лишь частично отражена в старых документах, которые к тому же сейчас считаются устаревшими.
Отсутствие четких правил и рекомендаций влечет за собой разночтения и непредсказуемость поведения веб-приложений. Еще одной сложностью является нетривиальный вопрос с кодированием массивов и комплексных структур внутри формы. Некоторые реализации используют повторяющиеся ключи с одинаковым именем, другие прибегают к синтаксису с квадратными скобками, а кто-то применяет индексы внутри них. Такой хаос встречается даже в популярных платформах и фреймворках, что значительно усложняет интеграцию и передачу данных между разными сервисами. Что касается загружаемых файлов, однозначный выбор есть только один — multipart/form-data.
Этот формат унаследован из почтовых протоколов и описан в RFC 7578. В отличие от предыдущего, он умеет передавать большие бинарные данные, однако его реализация полна курьезов и требует многочисленных компромиссов. Используемая многочастная структура данных отделяется специальными границами, которые формируются случайным образом на основе случайных последовательностей символов. Это необходимо, чтобы исключить конфликт с содержимым файлов, но при этом усложняет процесс парсинга и увеличивает объем передаваемых данных из-за дополнительной метаинформации и строк-разделителей. Формат multipart/form-data плохо подходит для высокопроизводительных задач, так как сервер не знает заранее точный размер каждой части, что заставляет обрабатывать закачки в потоковом режиме с дополнительной логикой.
Кроме того, такая сложность часто приводит к ошибкам и несовместимости между разными серверами и клиентами. Сам протокол HTTP 1.1, являющийся основой для работы с веб-формами, также вызывает немало нареканий. Несмотря на то что это одна из наиболее распространенных версий протокола, ее спецификации наполнены нестыковками и странными решениями, например, использование шестнадцатеричных чисел для обозначения размеров блоков при передаче данных кусками вызывает путаницу и неудобства. Также структура строки ответа с кодами статусов содержит обязательный пробел после числового кода статуса, без которого ответ становится некорректным.
Подобные мелочи негативно влияют на устойчивость и предсказуемость работы приложений. Возникает резонный вопрос, почему за все эти десятилетия не было внедрено более удобных и современных форматов для передачи данных форм. Попытки реформировать существующие подходы предпринимались, например, в 2014 году W3C сделала предложение использовать JSON для отправки данных форм. Такая идея выглядела многообещающей, поскольку JSON — гибкий, простой и понятный формат, который широко применяется в веб-разработке. Однако работа над этой инициативой была прекращена в 2015 году, вероятно из-за технических сложностей, несовместимости с браузерами и отсутствия объединяющей поддержки индустрии.
Помимо этого есть альтернативные протоколы для загрузки файлов, такие как tus, которые ориентированы на улучшение процесса передачи больших данных, но они не получили широкого распространения и по-прежнему требуют подключения сторонних библиотек и дополнительной настройки. Одной из самых больших проблем форм является их несоответствие современным требованиям к типам данных. Ни application/x-www-form-urlencoded, ни multipart/form-data не поддерживают передачу сложных структур, таких как вложенные объекты или массивы с многоуровневой вложенностью. Приходится довольствоваться примитивными ключ-значение структурами, что ограничивает возможности современных интерфейсов и ведет к раздутым, сложно поддерживаемым решениям на стороне сервера. Еще один важный аспект — вопросы безопасности и надежности передачи данных.
Старые форматы не предусматривают встроенной поддержки доказательства целостности или защиты от подделки содержимого, что открывает простые пути для атак и ошибочной обработки пользовательских данных. Несмотря на появление HTTP/2 и HTTP/3, которые оптимизируют передачу данных на уровне протокола, форматы отправки форм остаются прежними, поскольку входят в состав стандарта и взаимодействуют с ним на более высоком уровне. Это классический пример технологии, в которой эволюция протокола не сопровождается одновременным обновлением способов передачи самого контента. Отсутствие единой и современной стандартизации форматов форм негативно сказывается и на разработчиках, и на пользователях. Разработчикам приходится писать сложные парсеры, учитывающие огромное количество нюансов и исключений, а пользователи сталкиваются с ограничениями функционала, длительной загрузкой и непонятными ошибками.
Будущее веб-форм видится в переходе к более современным и гибким форматам данных, в частности JSON и другим сериализациям с поддержкой типов, вложенности и сжатия. Реализация таких стандартов потребует времени, консенсуса и сотрудничества между крупными игроками отрасли, включая разработчиков браузеров, серверных платформ и стандартных организаций. Пока же мы вынуждены использовать наследие прошлого, с его неуклюжими стандартами и архитектурными компромиссами. В итоге формы в вебе остаются одной из нерешенных проблем, над которой необходимо активно работать, чтобы сделать взаимодействие в интернете более удобным, надежным и современным.
