Dlaczego nie ma metod PUT i DELETE w formularzach HTML?

265

HTML4 / XHTML1 pozwala tylko GET i POST w formularzach, teraz wydaje się, że HTML5 zrobi to samo. Istnieje propozycja dodania tych dwóch, ale wydaje się, że nie zyskuje na popularności. Jakie były techniczne lub polityczne przyczyny nieuwzględnienia PUT i DELETE w wersji roboczej specyfikacji HTML5?

FilipK
źródło
7
HTML to język znaczników, HTTP to protokół
maniak ratchet,
51
@ratchet freak: Jestem tego świadomy. Niemniej jednak pytam konkretnie o HTML, ponieważ definiuje on tylko GET i POST jako dozwolone <form>metody.
FilipK,
Typowy scenariusz to formularz z danymi tabelarycznymi, w którym użytkownik musi umieścić więcej linii lub nie, ponieważ „więcej linii” jest decyzją użytkownika. Używanie Javascript + POST jest sztuczne, być może HTML6 pokaże alternatywną funkcję FORMULARZA do wykonania tego rodzaju operacji.
Peter Krauss
Odpowiedziałem na to pytanie, gdy ktoś inny zadał to pytanie na temat przepełnienia stosu, i uważam, że mój wkład ma coś do dodania do doskonałych odpowiedzi powyżej, dla każdego, kto czyta to na dole strony: o) Dlaczego przeglądarki nie obsługują żądań PUT i DELETE oraz kiedy oni
Nicholas Shanks
4
czy to jest nadal ważne? w3.org/TR/form-http-extensions/#http-delete-form
Jeff Puckett

Odpowiedzi:

348

To fascynujące pytanie. Pozostałe odpowiedzi tutaj są spekulatywne, aw niektórych przypadkach całkowicie błędne. Zamiast pisać tutaj moją opinię, faktycznie przeprowadziłem badania i znalazłem oryginalne źródła, które dyskutują, dlaczego usuwanie i wstawianie nie są częścią standardowego formularza HTML5.

Jak się okazuje, metody te zostały uwzględnione w kilku wczesnych wersjach roboczych HTML5 (!), Ale zostały później usunięte w kolejnych wersjach roboczych . Mozilla faktycznie zaimplementowała to również w wersji beta Firefoksa .

Jakie było uzasadnienie usunięcia tych metod z projektu? W3C omówił ten temat w raporcie o błędzie 10671 . Mike Amundsen opowiedział się za tym wsparciem:

Wykonywanie operacji PUT i DELETE w celu zmodyfikowania zasobów na serwerze źródłowym jest proste w przypadku nowoczesnych przeglądarek internetowych wykorzystujących obiekt XmlHttpRequest. W przypadku nieskryptowanych interakcji przeglądarki nie jest to takie proste. [...]

Ten wzorzec jest wymagany tak często, że kilka często używanych platform / bibliotek internetowych stworzyło „wbudowane” obejście. [...]

Inne uwagi:

  • Używanie POST jako tunelu zamiast PUT / DELETE może prowadzić do buforowania niepasujących dopasowań (np. Odpowiedzi POST są buforowalne , odpowiedzi PUT nie są (6), odpowiedzi DELETE nie są (7))
  • Użycie nie idempotentnej metody (POST) do wykonania idempotentnej operacji (PUT / DELETE) komplikuje odzyskiwanie z powodu awarii sieci (np. „Czy można bezpiecznie powtórzyć tę akcję?”).
  • [...]

Warto przeczytać cały jego post.

Tom Wardrop przedstawia również interesujący punkt:

HTML jest nierozerwalnie związany z HTTP. HTML to ludzki interfejs HTTP. Jest zatem automatycznie wątpliwe, dlaczego HTML nie obsługuje wszystkich odpowiednich metod w specyfikacji HTTP. Dlaczego maszyny mogą PUT i DELETE zasoby, a ludzie nie? [...]

Jest sprzeczne, że chociaż HTML dokłada wszelkich starań, aby zapewnić znaczniki semantyczne, do tej pory nie podejmował takich wysiłków, aby zapewnić semantyczne żądania HTTP.

Błąd został ostatecznie zamknięty jako „Nie naprawi” Ian Hickson, z następującym uzasadnieniem:

PUT jako metoda formularza nie ma sensu, nie chciałbyś PUT ładunku formularza. DELETE ma sens tylko wtedy, gdy nie ma ładunku, więc nie ma też większego sensu w przypadku formularzy.

To jednak nie koniec historii! Kwestia ta została zamknięta w W3C bug tracker i eskalacja do śledzenia błędów Grupy Roboczej HTML:

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

W tym momencie wydaje się, że głównym powodem, dla którego nie ma wsparcia dla tych metod, jest po prostu to, że nikt nie poświęcił czasu na napisanie dla niego kompleksowej specyfikacji.

Mark E. Haase
źródło
70
+1 za włożenie wysiłku badawczego i wykopanie szeregu zewnętrznych odnośników, aby właściwie odpowiedzieć na pytanie.
6
@shivakumar Myślę, że tak naprawdę pytasz, dlaczego zawracasz sobie głowę HTMLem, skoro JavaScript może już wykonać to zadanie? To uczciwe pytanie. Wydaje mi się, że pytanie OP pochodzi bardziej z ciekawości niż z praktyczności. HTML i HTTP to dwa standardy stworzone dla siebie, a jednak HTML wydaje się nie wiedzieć o niektórych podstawowych właściwościach HTTP. "Dlaczego?" jest naturalnym pytaniem.
Mark E. Haase
23
Z pewnością musisz podać ładunek dla PUT i dla USUŃ jest to możliwe? Także jeśli „nie ma sensu z formularzami”, to dlaczego ludzie o to proszą i dlaczego tak wiele, jeśli wbudowane w niego oprogramowanie działa. Dziwne, jak jedna osoba może po prostu zdecydować, czego reszta świata potrzebuje lub chce ...
Jonathan.
4
@mehaase Być może to tylko ja, ale uważam, że listy dyskusyjne są znacznie lepszym miejscem do dyskusji niż do wyrażenia ogólnego poparcia dla propozycji. Nie jestem skłonny do rozpoczynania nowego wątku na liście mailingowej public-html-comments, aby móc powiedzieć „Podoba mi się ta propozycja; formularze powinny mieć możliwość korzystania z innych metod HTTP”. Jako ktoś, kto dorastał we współczesnej sieci, chcę wiedzieć: „gdzie jest przycisk upvote?” ;-)
Ajedi32
6
@ Ajedi32 oto post: lists.w3.org/Archives/Public/public-html/2015Feb/0000.html Zachęcam wszystkich, którzy są zainteresowani, aby odpowiedzieć na ten post na publicznej liście dyskusyjnej HTML.
Mark E. Haase
12

GET i POST mają jasne, neutralne pod względem treści uzasadnienie. GET polega na pobieraniu zawartości adresu URL w sposób, który można bezpiecznie powtórzyć i ewentualnie buforować. POST to zrobić coś w sposób, który nie jest bezpieczny do powtarzania, wykonywania spekulacyjnego lub buforowania.

Nie było podobnego uzasadnienia dla PUT lub DELETE. Oba są całkowicie objęte POST. Tworzenie lub niszczenie zasobu to operacje, które nie są bezpieczne do powtarzania, nie są bezpieczne do wykonania spekulacyjnego i nie powinny być buforowane. Nie są dla nich potrzebne dodatkowe specjalne semantyki.

W zasadzie nie ma korzyści.

David Schwartz
źródło
22
Chociaż POST obejmuje PUT i DELETE, nadal widzę korzyści z posiadania oddzielnych metod. Wszystkie są objęte specyfikacją HTTP, a ich użycie jest zalecane w REST.
FilipK,
10
@David: To byłaby funkcja .
Donal Fellows
15
Uzasadnieniem jest to, że POST i DELETE mają różne - prawie przeciwne - znaczenia. Twierdzisz, że POST całkowicie obejmuje DELETE, ale POST nie jest idempotentny, a DELETE jest. Jak to wytłumaczysz? w3.org/Protocols/rfc2616/rfc2616-sec9.html
Mark E. Haase
14
Sprytna analogia, ale na nowo definiujesz, co oznacza „okładka”. W oryginalnej odpowiedzi masz na myśli „okładki” jak w „obsługuje wszystkie te same przypadki użycia”. Tutaj redefiniujesz „okładki”, aby oznaczać pewien rodzaj relacji taksonomicznej. Wytnijmy język: POST nie obsługuje tych samych przypadków użycia, co DELETE z powodu różnicy w idempotencji. GET nie obsługuje tych samych przypadków użycia co DELETE ze względu na inną semantykę. Obsługa DELETE zwiększyłaby funkcjonalność agenta użytkownika.
Mark E. Haase
13
Nie zgadzam się z tą odpowiedzią. niePOST jest idempotentny, dlatego po kliknięciu „wstecz” w przeglądarce wyświetli się brzydka strona z informacją, że formularz należy wysłać ponownie. Jednak gdyby tak było PUT, mógłby bezpiecznie ponownie wysłać PUTżądanie wyświetlenia dowolnej strony. Oczywiście pod warunkiem, że nie zepsuje interfejsu API, tworząc coś w rodzaju DELETE /resource/latest.
arg20
12

Zostało to podniesione w 2010 roku, ponieważ Bug 10671 rozważa dodanie obsługi PUT i DELETE jako metod formularza .

Wystąpiła umiarkowana reakcja zwrotna na tę „funkcję” i pewne ciężkie podejście, ale ostatecznie została eskalowana jako dwa problemy w śledzeniu błędów grup roboczych:

Problem ISSUE-196 spowodował, że podjęto decyzję o tym, aby nie wprowadzać żadnych zmian w specyfikacji, ponieważ specyfikacja HTML nie ogranicza obecnie sposobu obsługi odpowiedzi na żądania POST. Uważam, że ten konkretny problem został podniesiony podczas próby uzgodnienia często używanych wzorców przekierowań POST oraz tego, jak serwery ReSTful często dostarczają odpowiedzi 2xx krótkimi wiadomościami zamiast czegoś przydatnego do renderowania w przeglądarce.

Problem ISSUE-195 został przedstawiony przewodniczącym. Cameron Jones zgłosił się na ochotnika, pisząc propozycję zmiany 18 stycznia 2012 r., Którą złożył jako pierwszy roboczy projekt 29 maja 2014 r. Projekt przejdzie proces rekomendacji W3C .

Przy odrobinie szczęścia wkrótce stanie się to rekomendacją W3C i wdrożoną przez producentów przeglądarek i będzie wielkim krokiem naprzód w usuwaniu programów blokujących w celu stworzenia zunifikowanych, semantycznych i przyjaznych dla przeglądarki usług ReSTful. Wyobrażam sobie, że spowoduje to interesującą ewolucję wzorców usług. Dobra rozmowa Jona Moore'a - interfejsy API Hypermedia, które warto obejrzeć, zainteresowało mnie to, ale upadło przy pierwszej przeszkodzie (tej).

Stuart Wakefield
źródło
5

Rozumiem, że przeglądarki nie wiedzą, co zrobić, gdy wyślą PUT lub DELETE. POST zwykle przekierowuje na odpowiednią stronę, ale PUT i DELETE zwykle nie. To sprawia, że ​​są odpowiednie do wywoływania za pośrednictwem ajax lub rodzimego programu, ale nie z poziomu przeglądarki internetowej.

Nie mogę tego teraz powstrzymać, ale pamiętam, że czytałem jedną z list mailingowych HTML5, kiedy o tym dyskutowali.

maxpolun
źródło
4
Czy istnieje powód, dla którego PUT i DELETE nie mogą przekierowywać w taki sam sposób jak POST?
Ryan H
3
@maxpolun To prawdopodobnie lista mailingowa, do której się odwołujesz: lists.w3.org/Archives/Public/public-html-wg-issue-tracking/…
jordanbtucker
2
@RyanH Nie ma. Każda napotkana aplikacja, która wysyła żądanie usunięcia, odpowie przekierowaniem do indeksu.
Qwertie,
5

Historia

Myślę, że warto wspomnieć o pierwszym pojawieniu się formularzy HTML w RFC1866 (Rozdział 8.1) . Tutaj atrybut metody jest zdefiniowany następująco:

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".

Dalsze wyjaśnienia znajdują się w sekcji 8.2.2 - GET i sekcji 8.2.3 - POST

Należy pamiętać, że HTML 2.0 (listopad 1995) został określony przed HTTP 1.0 (maj 1996). Tak więc wszyscy używali HTTP tylko z GET (od HTTP 0.9) lub z rozszerzeniem POST. Ale tylko kilka serwerów WWW obsługiwało PUT i DELETE (jak podano w dodatku HTTP 1.0 ).

Myśli

Jeśli zastanowisz się, jak mógł rozwinąć się rozwój sieci semantycznej przez Bernersa-Lee, wydaje się jasne, że przeszła ona od rzeczywistych problemów do ogólnej koncepcji. Najpierw chciał udostępnić dokumenty. Dlatego potrzebował znaczników. Następnie chciał zapytać bazy danych o zawartość, więc potrzebował formularzy. Następnie chciał wprowadzić nowe dane do bazy danych. Więc używał formularzy z GET i POST. Potem mógł zdać sobie sprawę, że można wykonać każdą operację CRUD na danych ze zdalnego, więc HTTP został przedłużony, ale nigdy HTML, ponieważ było za późno (tylko kilka serwerów obsługiwało nowe operacje CRUD).

schmijos
źródło
-2

Po prostu rzucam dzikie przypuszczenia, ale prawdopodobnie dlatego, że HTTP w najlepszym przypadku nie jest zbyt dobry w kontroli dostępu, a ostatnią rzeczą, której wszyscy potrzebują, jest jeszcze więcej sposobów, aby złośliwe adresy URL mogły zagrozić słabo zabezpieczonej witrynie i / lub aplikacji.

HTTP nie jest tak naprawdę dobrym protokołem do przesyłania plików poza pobieraniem z serwera do klienta. Użyj FTP - lub jeszcze lepiej SFTP.

Shadur
źródło
12
Bezpieczeństwo nie ma na to wpływu. Nadal możesz wysyłać żądania PUT / Delete przez HTTP. curl --request PUT http://A.B.c/indexPytanie brzmi: dlaczego możesz uzyskać dostęp do tych poleceń za pomocą HTML?
Martin York
5
-1 Dzikie domysły na ogół nie są pomocne w przypadku SO.
Mark E. Haase
-4

Pobierz i wyślij to formaty przesyłania danych żądania.

Przypuszczam, że pytasz o przesłanie formularza do usługi RESTFUL. Ale zmiana standardu żądania HTTP nie ma sensu, aby założenia były celem żądania HTTP. Informacje o celu wypełnienia żądania najlepiej obsłużyć w polach wejściowych.

Posiadanie adresu oraz pobranie i wysłanie pozwala serwerowi poprawnie zinterpretować żądanie i jego wartości wejściowe. Stamtąd wartości wejściowe pozwalają na wysyłanie otwartych żądań do serwera i robienie tego, co chcesz. Na przykład możesz mieć pole, którego wartości to „wstaw” i „usuń”

Joe
źródło
5
-1 „Pobierz i wyślij to formaty przesyłania danych żądania.” Nie, są to metody HTTP, a nie „formaty”.
Mark E. Haase