En el clásico libro "RESTful Web Services" (O'Reilly, ISBN 978-0-596-52926-0) dice en la página 251 "Algunos firewalls bloquean HTTP PUT y DELETE pero no POST "RESTful PUT y DELETE y firewalls
¿Sigue siendo así?
Si es verdad, tengo que permitir POST sobrecargado para sustituir a DELETE.
Cortafuegos que bloquean HTTP PUT/DELETE generalmente bloquean las conexiones entrantes (a los servidores detrás del firewall). Suponiendo que tiene controles sobre el firewall que protege su aplicación, no debería tener que preocuparse por ello.
Además, los firewalls solo pueden bloquear PUT/DELETE si están realizando una inspección profunda del tráfico de la red. El cifrado evitará que los cortafuegos analicen la URL, por lo que si usa HTTPS (está protegiendo sus datos con SSL, ¿no?) Los clientes que accedan a su servicio web podrán usar cualquiera de los cuatro verbos HTTP estándar.
Estamos usando HTTPS. (Duh - Debería haberme dado cuenta de que los firewalls ni siquiera pueden ver los encabezados.) ¡Gracias! –
Excelente. La aplicación de HTTPS resolvió este problema para mí. Para aquellos que están jugando en casa, mi servidor de balanceo (libra) informaba cosas como: '6 de septiembre 13:00:08 bal01 libra: (b6515b70) error leído de 1.2.3.4: se agotó el tiempo de espera de la conexión': hasta el día de hoy no tenía idea de que se tratara de solicitudes DELETE, bloqueadas por un firewall. Notablemente, las solicitudes PUT estaban llegando bien. –
Algunos cortafuegos de 7 capas podrían analizar el tráfico hasta este grado. Pero no estoy seguro de cuántos lugares los configurarían como tales. Puede comprobar en serverfault.com para ver qué tan popular podría ser esa configuración (también podría consultar siempre con su personal de TI)
Puede configurar un servidor de seguridad para lo que desee (al menos en teoría) así que don No se sorprenda si algunos administradores de sistema bloquean HTTP PUT/DELETE.
El peligro de HTTP PUT/DELETE se refiere a algunos servidores mal configurados: PUT reemplaza documentos (y DELETE los elimina ;-) en el servidor de destino. Entonces, algunos administradores de sistemas deciden directamente para bloquear PUT en caso de que se abra una grieta en alguna parte.
Por supuesto estamos hablando de servidores de seguridad que actúan en "capa 7" y no sólo en la capa IP ;-)
yo no me preocuparía por la sobrecarga de un POST para apoyar una solicitud DELETE.
HTML 4.0 y XHTML 1.0 solamente obtener apoyo y POST peticiones (VIa) por lo que es un lugar común para túnel de un PUT/DELETE a través de un campo de formulario oculto que es leído por el servidor y dispathced apropiadamente. Esta técnica preserva la compatibilidad entre los navegadores y le permite ignorar los problemas del firewall.
Ruby On Rails y .NET manejan solicitudes RESTful de esta manera.
Como un aparte GET, POST, PUT & las solicitudes DELETE son totalmente compatibles a través del objeto de solicitud XMLHttpRequest en este momento. XHTML 2.0 es oficialmente compatible con GET, POST, PUT & DELETE también.
Además, HTML5 solo permite obtener/publicar en formularios aunque ASP.NET MVC, por ejemplo, utiliza un campo de formulario X-HTTP-Method-Override oculto (si elige poner uno allí por supuesto) para lograr la asignación del servidor al HttpPut correcto o Método HttpDelete –
El problema es cómo saber si la solicitud será bloqueada, y en ese caso túnel DELETE sobre POST: no estoy realmente preparado para romper REST por 0.02% [citación requerida] de usuarios (mi medida de qué tan seguido sucede). –