¿Por qué no hay métodos PUT y DELETE en formularios HTML?

265

HTML4 / XHTML1 solo permite GET y POST en formularios, ahora parece que HTML5 hará lo mismo. Hay una propuesta para agregar estos dos, pero no parece estar ganando terreno. ¿Cuáles fueron las razones técnicas o políticas para no incluir PUT y DELETE en el borrador de la especificación HTML5?

FilipK
fuente
77
HTML es el lenguaje de marcado, HTTP es el protocolo
ratchet freak
51
@ratchet freak: Soy consciente de eso. Sin embargo, estoy preguntando específicamente sobre HTML, ya que define solo GET y POST como <form>métodos permitidos .
FilipK
Un escenario típico es un formulario con datos tabulares, donde el usuario necesita PONER más líneas o no, ya que "más líneas" son decisiones del usuario. El uso de Javascript + POST es artificial, quizás HTML6 muestre una función FORM alternativa para realizar este tipo de operaciones.
Peter Krauss
Respondí esta pregunta cuando alguien más la hizo en Stack Overflow, y siento que mi contribución allí tiene algo que agregar a las excelentes respuestas anteriores, para cualquiera que lea esto más adelante en la página: o) ¿Por qué los navegadores no admiten solicitudes PUT y DELETE y ¿Cuándo lo harán?
Nicholas Shanks
44
¿Sigue siendo válido? w3.org/TR/form-http-extensions/#http-delete-form
Jeff Puckett el

Respuestas:

348

Esta es una pregunta fascinante. Las otras respuestas aquí son todas especulativas y, en algunos casos, totalmente incorrectas. En lugar de escribir mi opinión aquí, en realidad investigué un poco y encontré fuentes originales que analizan por qué eliminar y colocar no son parte del estándar de formulario HTML5.

Resulta que estos métodos se incluyeron en varios borradores HTML5 iniciales (!), Pero luego se eliminaron en los borradores posteriores . Mozilla también había implementado esto en una versión beta de Firefox .

¿Cuál fue la razón para eliminar estos métodos del borrador? El W3C discutió este tema en el informe de error 10671 . Mike Amundsen argumentó a favor de este apoyo:

Ejecutar PUT y DELETE para modificar recursos en el servidor de origen es sencillo para los navegadores web modernos que usan el objeto XmlHttpRequest. Para las interacciones de navegador sin script, esto no es tan simple. [...]

Este patrón se requiere con tanta frecuencia que varios frameworks / bibliotecas web de uso común han creado una solución "incorporada". [...]

Otras Consideraciones:

  • Usar POST como un túnel en lugar de usar PUT / DELETE puede conducir a errores de coincidencia de almacenamiento en caché (por ejemplo, las respuestas POST son almacenables en caché , las respuestas PUT no son (6), las respuestas DELETE no son (7))
  • El uso de un método no idempotente (POST) para realizar una operación idempotente (PUT / DELETE) complica la recuperación debido a fallas de la red (por ejemplo, "¿Es seguro repetir esta acción?").
  • [...]

Vale la pena leer su publicación completa.

Tom Wardrop también hace un punto interesante:

HTML está inextricablemente unido a HTTP. HTML es la interfaz humana de HTTP. Por lo tanto, es automáticamente cuestionable por qué HTML no admite todos los métodos relevantes en la especificación HTTP. ¿Por qué las máquinas PUEDEN PONER y BORRAR recursos, pero los humanos no pueden? [...]

Es contradictorio que, si bien HTML hace todo lo posible para garantizar el marcado semántico, hasta la fecha no ha hecho ningún esfuerzo para garantizar las solicitudes HTTP semánticas.

El error finalmente se cerró como No lo solucionará Ian Hickson, con la siguiente justificación:

PUT como método de formulario no tiene sentido, no querrás PONER una carga útil de formulario. DELETE solo tiene sentido si no hay carga útil, por lo que tampoco tiene mucho sentido con los formularios.

Sin embargo, ¡ese no es el final de la historia! El problema se cerró en el rastreador de errores del W3C y pasó al rastreador de problemas del Grupo de trabajo HTML:

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

En este punto, parece que la razón principal por la que no hay soporte para estos métodos es simplemente que nadie se ha tomado el tiempo para escribir una especificación completa para ello.

Mark E. Haase
fuente
70
+1 por poner en marcha el esfuerzo de investigación y desenterrar una serie de referencias externas para responder adecuadamente la pregunta.
66
@shivakumar Creo que lo que realmente estás preguntando es ¿por qué molestarse con HTML cuando JavaScript ya puede hacer el trabajo? Esa es una pregunta justa. Supongo que la pregunta del OP proviene más de un lugar de curiosidad que de practicidad. HTML y HTTP son dos estándares hechos el uno para el otro, y sin embargo, HTML parece desconocer algunas de las propiedades más básicas de HTTP. "¿Por qué?" Es una pregunta natural para hacer.
Mark E. Haase
23
¿Seguramente tiene que incluir una carga útil para PUT y para DELETE es posible? Además, si "no tiene mucho sentido con las formas", entonces ¿por qué la gente pidiendo y por qué lo hace mucho si el software que soluciones alternativas construidas en Odd cómo una persona solo puede decidir lo que el resto del mundo necesita o quiere ....
Jonathan
44
@mehaase Además, tal vez solo soy yo, pero creo que las listas de correo son un lugar mucho mejor para el debate que para expresar el apoyo general de una propuesta. No estoy dispuesto a comenzar un nuevo hilo en la lista de correo public-html-comments solo para poder decir "Me gusta esta propuesta; los formularios deberían poder usar otros métodos HTTP". Como alguien que creció en la web moderna, lo que quiero saber es: "¿dónde está el botón de votación?" ;-)
Ajedi32
66
@ Ajedi32 aquí está la publicación: lists.w3.org/Archives/Public/public-html/2015Feb/0000.html Animo a todos los interesados ​​a responder a esta publicación en la lista de correo public-html.
Mark E. Haase
12

GET y POST tienen una lógica clara de contenido neutral. OBTENER es recuperar el contenido de una URL de forma segura para repetir y posiblemente almacenar en caché. POST es hacer algo de una manera que no sea seguro repetir, ejecutar especulativamente o almacenar en caché.

No hubo una justificación similar para PUT o DELETE. Ambos están completamente cubiertos por POST. Crear o destruir un recurso son operaciones que no son seguras de repetir, no son seguras de ejecutar especulativamente y no deben almacenarse en caché. No se necesitan semánticas especiales adicionales para ellos.

Entonces, básicamente, no hay beneficio.

David Schwartz
fuente
22
Aunque POST cubre PUT y DELETE, aún puedo ver el beneficio de tener métodos separados. Todos ellos están cubiertos en la especificación HTTP y se recomienda su uso en REST.
FilipK
10
@David: Esa sería una característica .
Donal Fellows
15
La razón es que POST y DELETE tienen significados diferentes, casi opuestos. Afirma que POST cubre completamente ELIMINAR, pero POST no es idempotente y DELETE sí. ¿Cómo explicas eso? w3.org/Protocols/rfc2616/rfc2616-sec9.html
Mark E. Haase
14
Analogía inteligente, pero estás redefiniendo lo que significa "cubre". En su respuesta original, quiere decir "cubiertas" como en "admite todos los mismos casos de uso". Aquí está redefiniendo "portadas" para que signifique algún tipo de relación taxonómica. Cortemos el lenguaje: POST no admite los mismos casos de uso que DELETE debido a la diferencia de idempotencia. GET no admite los mismos casos de uso que DELETE debido a la semántica diferente. La compatibilidad con DELETE aumentaría la funcionalidad del agente de usuario.
Mark E. Haase
13
No estoy de acuerdo con esta respuesta. noPOST es idempotente, por eso cuando hace clic en "Atrás" en su navegador, mostrará una página fea que dice que el formulario debe reenviarse. Sin embargo , si hubiera sido un PUT, podría reenviar de forma segura la PUTsolicitud para mostrar la página que debería obtener. Siempre que, por supuesto, uno no arruine la API creando una especie de DELETE /resource/latest.
arg20
12

Esto se planteó en 2010 ya que el Bug 10671 considera agregar soporte para PUT y DELETE como métodos de formulario .

Hubo una cantidad moderada de retroceso para esta "característica" y algo de mano dura, pero finalmente esto se intensificó como dos problemas en el rastreador de errores de los Grupos de trabajo:

El problema ISSUE-196 resultó en una decisión de consenso de no realizar ningún cambio en la especificación ya que la especificación HTML no restringe actualmente cómo se manejan las respuestas a las solicitudes POST. Creo que este problema en particular surgió al tratar de conciliar los patrones de redireccionamiento POST que se usan comúnmente y cómo los servidores ReSTful a menudo proporcionan respuestas 2xx con mensajes cortos en lugar de algo útil para representar en un navegador.

El tema ISSUE-195 fue presentado a los presidentes. Cameron Jones se ofreció como voluntario para escribir una propuesta de cambio el 18 de enero de 2012 que presentó para convertirse en el primer borrador de trabajo el 29 de mayo de 2014. El borrador pasará por el proceso de recomendaciones del W3C .

Con suerte, esto pronto se convertirá en una recomendación del W3C y será implementado por los vendedores de navegadores, y sería un gran paso adelante para eliminar los bloqueadores para producir servicios ReSTful unificados, semánticos y amigables para el navegador. Me imagino que esto provocará una evolución interesante en los patrones de servicio. Hay una buena charla de Jon Moore: API de Hypermedia que vale la pena ver, esto me llamó la atención, pero cayó en el primer obstáculo (este).

Stuart Wakefield
fuente
5

Tengo entendido que los navegadores no saben qué hacer una vez que envían un PUT o un DELETE. Una POST generalmente redirigirá a una página apropiada, pero PUT y DELETE generalmente no lo hacen. Esto los hace apropiados para llamar a través de ajax o un programa nativo, pero no desde un formulario de navegador web.

No puedo evitarlo en este momento, pero recuerdo haber leído una de las listas de correo html5 cuando estaban discutiendo esto.

maxpolun
fuente
44
¿Hay alguna razón por la cual PUT y DELETE no pueden o no redirigen de la misma manera que POST?
Ryan H
3
@maxpolun Esta es probablemente la lista de correo a la que se refiere: lists.w3.org/Archives/Public/public-html-wg-issue-tracking/…
jordanbtucker
2
@RyanH No hay. Cada aplicación que he encontrado que envía una solicitud de eliminación responderá con una redirección al índice.
Qwertie
5

Historia

Creo que vale la pena mencionar la primera aparición de formularios html en el RFC1866 (Sección 8.1) . Aquí el atributo del método se define de la siguiente manera:

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

Las explicaciones adicionales se encuentran en la Sección 8.2.2 - GET y la Sección 8.2.3 - POST

Tenga en cuenta que HTML 2.0 (noviembre de 1995) se especificó antes de HTTP 1.0 (mayo de 1996). Entonces, todos usaron HTTP solo con GET (a partir de HTTP 0.9) o con la extensión POST. Pero solo unos pocos servidores web admitieron PUT y DELETE (como se indica en el Apéndice HTTP 1.0 ).

Pensamientos

Si piensa en cómo podría haber evolucionado el desarrollo de la web semántica de Berners-Lee, parece claro que pasó de problemas reales a un concepto general. Primero quería compartir documentos. Por lo tanto, necesitaba un marcado. Luego quiso consultar el contenido de las bases de datos, por lo que necesitaba formularios. Luego quiso poner nuevos datos en la base de datos. Entonces usó formularios con GET y POST. Después de eso, es posible que se haya dado cuenta de que puede realizar todas las operaciones CRUD en los datos de forma remota, por lo que HTTP se amplió pero nunca HTML porque era demasiado tarde (solo unos pocos servidores admitían las nuevas operaciones CRUD).

schmijos
fuente
-2

Simplemente lanzando una suposición descabellada, pero probablemente porque HTTP no es terriblemente bueno con el control de acceso en el mejor de los casos, y lo último que todos necesitan es aún más formas para que las URL maliciosas comprometan un sitio web y / o aplicación mal asegurados.

HTTP no es realmente un buen protocolo para la transferencia de archivos que no sea la descarga del servidor al cliente. Use FTP, o mejor aún, SFTP.

Shadur
fuente
12
La seguridad no tiene relación con esto. Aún puede realizar solicitudes PUT / Delete a través de HTTP. curl --request PUT http://A.B.c/indexLa pregunta es por qué puede acceder a estos comandos a través de HTML.
Martin York
55
-1 Las conjeturas salvajes generalmente no son útiles en SO.
Mark E. Haase
-4

Obtener y publicar son formatos de transmisión de los datos de la solicitud.

Supongo que está preguntando acerca de cómo enviar un formulario a un servicio RESTFUL. Pero no tiene sentido cambiar el estándar de solicitud http para hacer suposiciones el propósito de la solicitud http. La información sobre el propósito que cumple la solicitud se maneja mejor en los campos de entrada.

Tener una dirección y obtener y publicar permite al servidor interpretar la solicitud y sus valores de entrada correctamente. A partir de ahí, los valores de entrada le permiten realizar solicitudes abiertas al servidor y hacer lo que quiera. Por ejemplo, puede tener un campo cuyos valores son "poner" y "eliminar"

Joe
fuente
55
-1 "Obtener y publicar son formatos de transmisión de los datos de la solicitud". No, son métodos HTTP, no "formatos".
Mark E. Haase