Dlaczego nie ma metod PUT i DELETE w formularzach HTML?

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?

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.

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.

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:

• WYDANIE-195: Ulepszenie generowania żądań HTTP z formularzy
• ZAGADNIENIE-196: Zdefiniuj zachowanie obsługi odpowiedzi HTTP przez użytkownika

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

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.

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

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.

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ń”