Почему в формах HTML нет методов PUT и DELETE?

HTML4 / XHTML1 допускает только GET и POST в формах, теперь кажется, что HTML5 сделает то же самое. Есть предложение добавить эти два, но оно, похоже, не набирает обороты. По каким техническим или политическим причинам не было включено PUT и DELETE в черновик спецификации HTML5?

Это увлекательный вопрос. Все остальные ответы здесь носят умозрительный характер, а в некоторых случаях совершенно неверны. Вместо того, чтобы писать свое мнение здесь, я действительно провел некоторое исследование и нашел оригинальные источники, которые обсуждают, почему удаление и вставка не являются частью стандарта формы HTML5.

Как оказалось, эти методы были включены в несколько ранних черновиков HTML5 (!), Но позже были удалены в последующих черновиках . Mozilla также реализовала это в бета-версии Firefox .

Что послужило основанием для удаления этих методов из проекта? W3C обсуждал эту тему в сообщении об ошибке 10671 . Майк Амундсен высказался в пользу этой поддержки:

Выполнение PUT и DELETE для изменения ресурсов на исходном сервере является простым для современных веб-браузеров, использующих объект XmlHttpRequest. Для незашифрованных браузерных взаимодействий это не так просто. [...]

Этот шаблон требуется так часто, что несколько часто используемых веб-фреймворков / библиотек создают «встроенный» обходной путь. [...]

Другие соображения:

• Использование POST в качестве туннеля вместо использования PUT / DELETE может привести к несоответствию кэширования (например, ответы POST кэшируются , ответы PUT - нет (6), ответы DELETE - нет (7))
• Использование неидемпотентного метода (POST) для выполнения идемпотентной операции (PUT / DELETE) усложняет восстановление из-за сбоев сети (например, «Безопасно ли повторять это действие?»).
• [...]

Стоит прочитать весь его пост.

Том Уордроп также делает интересное замечание:

HTML неразрывно связан с HTTP. HTML - это человеческий интерфейс HTTP. Поэтому автоматически возникает вопрос, почему HTML не поддерживает все соответствующие методы в спецификации HTTP. Почему машины могут ПОСТАВЛЯТЬ и УДАЛЯТЬ ресурсы, а люди - нет? [...]

Противоречиво, что хотя HTML идет на все, чтобы обеспечить семантическую разметку, на сегодняшний день он не предпринимал таких усилий для обеспечения семантических HTTP-запросов.

Иан Хиксон в конце концов исправил ошибку « Не исправлю» со следующим объяснением:

PUT как метод формы не имеет смысла, вы не хотите помещать полезную нагрузку формы. DELETE имеет смысл только в том случае, если нет полезной нагрузки, поэтому он не имеет особого смысла и с формами.

Однако это еще не конец истории! Проблема была закрыта в трекере ошибок W3C и перешла в трекер проблем рабочей группы HTML:

https://www.w3.org/html/wg/tracker/issues/195

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

GET и POST имеют четкое, нейтральное к содержанию обоснование. GET предназначен для получения содержимого URL-адреса таким образом, чтобы его можно было безопасно повторить и, возможно, кэшировать. POST - это что-то, что не безопасно повторять, спекулятивно выполнять или кэшировать.

Не было аналогичного обоснования для PUT или DELETE. Они оба полностью покрыты POST. Создание или уничтожение ресурса - это операции, которые небезопасно повторять, небезопасно выполнять спекулятивно и не должны кэшироваться. Для них не требуется никакой дополнительной специальной семантики.

Так что в принципе нет никакой пользы.

Эта проблема была поднята в 2010 году, поскольку ошибка 10671 предусматривает добавление поддержки PUT и DELETE в качестве методов формы .

У этой «особенности» было небольшое количество откатов и некоторая неуклюжесть, но в конечном итоге это обострилось из-за двух проблем в трекере ошибок рабочих групп:

• ВЫПУСК-195: Улучшить генерацию http-запроса из форм
• ПРОБЛЕМА 196: Определить поведение обработки ответа http пользовательского агента

Проблема ISSUE-196 привела к принятию консенсусом решения не вносить изменений в спецификацию, поскольку спецификация HTML в настоящее время не ограничивает обработку ответов на запросы POST. Я полагаю, что эта конкретная проблема возникла при попытке согласовать часто используемые шаблоны перенаправления POST и то, как серверы ReSTful часто предоставляют ответы 2xx с короткими сообщениями, а не с помощью чего-либо полезного для отображения в браузере.

Выпуск -195 был представлен на кафедре. Кэмерон Джонс выступил добровольно, написав предложение об изменении 18 января 2012 года, которое он представил, чтобы стать первым рабочим проектом 29 мая 2014 года. Проект будет проходить через процесс рекомендаций W3C .

Если повезет, это скоро станет рекомендацией W3C и будет реализовано поставщиками браузеров и станет большим шагом вперед в устранении блокировщиков для создания унифицированных, семантических и дружественных браузеру сервисов ReSTful. Я предполагаю, что это вызовет интересную эволюцию в шаблонах обслуживания. Джон Мур (Jon Moore) говорит о том, что API-интерфейсы Hypermedia заслуживают внимания, меня это заинтересовало, но они упали с первого же препятствия (вот этого).

Насколько я понимаю, браузеры не знают, что делать после отправки PUT или DELETE. POST обычно перенаправляет на соответствующую страницу, но PUT и DELETE обычно этого не делают. Это делает их подходящими для вызова через ajax или нативную программу, но не из формы веб-браузера.

Я не могу сейчас это скрыть, но я помню, как читал один из списков рассылки html5, когда они обсуждали это.

история

Я думаю, что стоит упомянуть о первом появлении html-форм в RFC1866 (раздел 8.1) . Здесь атрибут метода определяется следующим образом:

METHOD
        selects a method of accessing the action URI. The set of
        applicable methods is a function of the scheme of the
        action URI of the form. See 8.2.2, "Query Forms:
        METHOD=GET" and 8.2.3, "Forms with Side-Effects:
        METHOD=POST".

Дальнейшие объяснения находятся в Разделе 8.2.2 - GET и Разделе 8.2.3 - POST

Имейте в виду, что HTML 2.0 (ноябрь 1995 г.) был указан до HTTP 1.0 (май 1996 г.). Таким образом, все использовали HTTP только с GET (с HTTP 0.9) или с расширением POST. Но только несколько веб-серверов поддерживают PUT и DELETE (как указано в Приложении HTTP 1.0 ).

мысли

Если вы думаете о том, как развитие семантической сети Бернерс-Ли могло развиваться, кажется очевидным, что она перешла от реальных проблем к общей концепции. Сначала он хотел поделиться документами. Поэтому ему нужна разметка. Затем он захотел запросить у баз данных контент, поэтому ему нужны были формы. Затем он хотел поместить новые данные в базу данных. Поэтому он использовал формы с GET и POST. После этого он, возможно, понял, что вы можете выполнять каждую операцию CRUD с данными удаленно, поэтому HTTP был расширен, но не HTML, потому что было слишком поздно (только несколько серверов поддерживали новые операции CRUD).

Просто выбрасываю дикие предположения, но, возможно, потому, что HTTP не очень хорошо справляется с управлением доступом в лучшие времена, и последнее, что всем нужно, - это еще больше способов для вредоносных URL-адресов скомпрометировать плохо защищенный веб-сайт и / или приложение.

HTTP не очень хороший протокол для передачи файлов, кроме загрузки с сервера на клиент. Используйте FTP - или еще лучше, SFTP.

Get и post - это форматы передачи данных запроса.

Я полагаю, что вы спрашиваете о том, чтобы сделать отправку формы в RESTFUL сервис. Но не имеет смысла изменять стандарт http-запроса, чтобы сделать предположения целью http-запроса. Информация о цели, которую заполняет запрос, лучше всего обрабатывается в полях ввода.

Наличие адреса, get и post позволяет серверу правильно интерпретировать запрос и его входные значения. Оттуда входные значения позволяют вам делать открытые запросы к серверу и делать все, что вы хотите. Например, у вас может быть поле со значениями «положить» и «удалить»