Esta es una pregunta fascinante. Las otras respuestas aquí son todas especulativas, y en algunos casos son totalmente incorrectas. En lugar de escribir mi opinión aquí, realicé algunas investigaciones y encontré fuentes originales que explican por qué delete y put no forman parte del formulario estándar de HTML5.
Como resultado, estos métodos fueron incluidos en varios borradores tempranos de HTML5 (!), pero luego se eliminaron en borradores posteriores . Mozilla realmente implementó este en una versión beta de Firefox , también.
¿Cuál fue la razón para eliminar estos métodos del borrador? El W3C trató este tema en 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 utilizan el objeto XmlHttpRequest. Para interacciones de navegador sin guiones esto no es tan simple. [...]
Este patrón se requiere tan a menudo que varios marcos / bibliotecas web de uso común han creado una solución "incorporada". [...]
Otras consideraciones:
- El uso de POST como un túnel en lugar de usar PUT / DELETE puede llevar a errores en el almacenamiento en caché (por ejemplo, las respuestas de POST son almacenable en caché , las respuestas PUT no lo son (6), las respuestas BORRADAS no lo 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 en la red (por ejemplo, "¿Es seguro repetir esta acción?").
- [...]
Vale la pena leer todo su post.
Tom Wardrop también hace un punto interesante:
HTML está inextricablemente vinculado 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é pueden las máquinas PONER y BORRAR recursos, pero los humanos no pueden? [...]
Es contradictorio que, si bien el HTML hace todo lo posible para garantizar el marcado semántico, hasta la fecha no ha realizado ningún esfuerzo para garantizar las solicitudes HTTP semánticas.
El error se cerró finalmente como No se solucionará por Ian Hickson, con el siguiente razonamiento:
PONER como método de formulario no tiene sentido, no querría PONER una carga útil de formulario. BORRAR 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 se escaló al rastreador de problemas del Grupo de trabajo HTML:
enlace
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 él.