Take the 2-minute tour ×

In the classic "RESTful Web Services" book (O'Reilly, ISBN 978-0-596-52926-0) it says on page 251 "Some firewalls block HTTP PUT and DELETE but not POST."

Is this still true?

If it's true I have to allow overloaded POST to substitute for DELETE.

share|improve this question
The issue is how to tell if the request will be blocked, and in that case tunnel DELETE over POST: I'm not really prepared to break REST for 0.02% [citation required] of users (my measure of how often this happens). –  Matthew Schinckel Sep 6 '12 at 3:11

4 Answers 4

up vote 6 down vote accepted

Firewalls blocking HTTP PUT/DELETE are typically blocking incoming connections (to servers behind the firewall). Assuming you have controls over the firewall protecting your application, you shouldn't need to worry about it.

Also, firewalls can only block PUT/DELETE if they are performing deep inspection on the network traffic. Encryption will prevent firewalls from analyzing the URL, so if you're using HTTPS (you are protecting your data with SSL, right?) clients accessing your web service will be able to use any of the standard four HTTP verbs.

share|improve this answer
We are using HTTPS. (Duh -- I should have realized that firewalls can't even see the headers.) Thanks! –  Mark Lutton Dec 12 '09 at 0:55
Excellent. Enforcing HTTPS resolved this issue for me. For those that are playing along at home, my balancing server (pound) was reporting things like: Sep 6 13:00:08 bal01 pound: (b6515b70) error read from Connection timed out: I had no idea until today that these were DELETE requests, blocked by a firewall. Notably, PUT requests were coming through fine. –  Matthew Schinckel Sep 6 '12 at 3:10

Some 7 layer firewalls could analyze traffic to this degree. But I'm not sure how many places would configure them as such. You might check on serverfault.com to see how popular such a config might be (you could also always check with your IT staff)

share|improve this answer

You can configure a firewall to whatever you want ( at least in theory ) so don't be surprised if some sys admins do block HTTP PUT/DELETE.

The danger of HTTP PUT/DELETE is concerning some mis-configured servers: PUT replaces documents (and DELETE deletes them ;-) on the target server. So some sys admins decide up right to block PUT in case a crack is opened somewhere.

Of course we are talking about Firewalls acting at "layer 7" and not just at the IP layer ;-)

share|improve this answer

I would not worry about overloading a POST to support a DELETE request.

HTML 4.0 and XHTML 1.0 only support GET and POST requests (via ) so it is commonplace to tunnel a PUT/DELETE via a hidden form field which is read by the server and dispathced appropriately. This technique preserves compatibility across browsers and allows you to ignore any firewall issues.

Ruby On Rails and .NET both handle RESTful requests in this fashion.

As an aside GET, POST, PUT & DELETE requests are fully supported through the XMLHttpRequest request object at present. XHTML 2.0 's officially supports GET, POST, PUT & DELETE as well.

share|improve this answer
in addition HTML5 only allows get/post on forms although ASP.NET MVC for example uses a hidden X-HTTP-Method-Override form field (if you choose to put one there of course) to achieve server mapping to the correct HttpPut or HttpDelete method –  Adam Tuliper - MSFT Sep 17 '13 at 5:27

Your Answer


