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

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?

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.

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.

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:

• NÚMERO 195: Mejora la generación de solicitudes http a partir de formularios
• PROBLEMA 196: Definir el comportamiento de manejo de respuesta http del agente de usuario

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

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.

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

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.

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"