Im klassischen Buch "RESTful Web Services" (O'Reilly, ISBN 978-0-596-52926-0) heißt es auf Seite 251 "Einige Firewalls blockieren HTTP PUT und DELETE, aber nicht POST . "RESTful PUT und DELETE und Firewalls
Ist das immer noch wahr?
Wenn es wahr ist, muss ich zulassen, dass überladene POST für DELETE ersetzen.
Firewalls, die HTTP PUT/DELETE blockieren, blockieren normalerweise eingehende Verbindungen (zu Servern hinter der Firewall). Vorausgesetzt, Sie haben die Kontrolle über die Firewall, die Ihre Anwendung schützt, sollten Sie sich keine Sorgen machen.
Außerdem können Firewalls PUT/DELETE nur blockieren, wenn sie eine eingehende Überprüfung des Netzwerkverkehrs durchführen. Die Verschlüsselung verhindert, dass Firewalls die URL analysieren. Wenn Sie also HTTPS verwenden (Sie schützen Ihre Daten mit SSL, oder?), Können Clients, die auf Ihren Webdienst zugreifen, eines der vier Standard-HTTP-Verben verwenden.
Wir verwenden HTTPS. (Duh - ich hätte erkennen sollen, dass Firewalls die Header nicht einmal sehen können.) Danke! –
Ausgezeichnet. Die Durchsetzung von HTTPS hat dieses Problem für mich gelöst. Für diejenigen, die zu Hause spielen, berichtete mein Balancing-Server (Pfund) Dinge wie: '6. September 13:00:08 bal01 Pfund: (b6515b70) Fehler gelesen von 1.2.3.4: Zeitüberschreitung der Verbindung: Ich hatte bis heute keine Ahnung, dass es sich um DELETE-Anfragen handelte, die von einer Firewall blockiert wurden. Bemerkenswerterweise kamen PUT-Anfragen gut durch. –
Einige 7-Layer-Firewalls konnten den Datenverkehr in diesem Ausmaß analysieren. Aber ich bin nicht sicher, wie viele Orte sie als solche konfigurieren würden. Sie könnten auf serverfault.com überprüfen, wie beliebt solch eine Konfiguration sein könnte (Sie könnten auch immer mit Ihrem IT-Personal überprüfen)
Sie können eine Firewall konfigurieren, was auch immer Sie wollen (zumindest in der Theorie) so don Sei nicht überrascht, wenn einige sys-Admins HTTP PUT/DELETE blockieren.
Die Gefahr von HTTP PUT/DELETE betrifft einige falsch konfigurierte Server: PUT ersetzt Dokumente (und DELETE löscht sie ;-) auf dem Zielserver. So entscheiden sich manche Systemadministratoren, PUT zu sperren, falls irgendwo ein Crack geöffnet wird.
Natürlich sprechen wir über Firewalls auf „Schicht 7“ handeln und nicht nur auf der IP-Schicht ;-)
Ich würde nicht um eine Überlastung ein POST Sorge eine DELETE-Anfrage zu unterstützen.
HTML 4.0 und XHTML 1.0 nur Unterstützung GET und POST-Anfragen (über), so ist es üblich, ein PUT/DELETE über ein verstecktes Formularfeld zu tunneln, das vom Server gelesen und entsprechend verteilt wird. Diese Technik bewahrt die Kompatibilität zwischen Browsern und ermöglicht es Ihnen, Firewall-Probleme zu ignorieren.
Ruby On Rails und .NET behandeln RESTful-Anfragen auf diese Weise.
Als eine Seite GET, POST, PUT & DELETE-Anfragen werden derzeit vollständig durch die XMLHttpRequest Anfrage Objekt unterstützt. XHTML 2.0 unterstützt offiziell GET, POST, PUT & LÖSCHEN auch.
zusätzlich HTML5 erlaubt nur Get/Post auf Formularen, obwohl ASP.NET MVC zum Beispiel ein verstecktes X-HTTP-Method-Override-Formularfeld verwendet (wenn Sie eines dort natürlich setzen), um Server-Mapping auf die richtige HttpPut oder zu erreichen HttpDelete-Methode –
Das Problem ist, wie man erkennt, wenn die Anfrage blockiert wird, und in diesem Fall tunnel DELETE über POST: Ich bin nicht wirklich bereit, REST für 0,02% [Zitat erforderlich] von Benutzern zu brechen (mein Maß wie oft dies) das passiert). –