Are all HTTP methods/verbs accepted by APACHE and NGINX?

Question

In a talk I had recently, one of the speakers commented that the only methods that, in fact, the APACHE and the NGINX accept/support are methods/verbs GET and POST.

The speaker further clarifies that when other methods, such as PUT, PATCH, DELETE and others are used, the APACHE and the NGINX mask the method, ie are converted to GET and POST and passed to the application containing a flag of the old method sent. So the application will know which method, actually was sent.

My question is: The methods/verbs are actually accepted by APACHE and the NGINX or the procedure contextualized in the question is what actually happens?

Answer 1

They are, even by the IIS, except that your HTTP server is outdated (be an older version), depending on the type of server you use it will issue an HTTP error by chance invent a method that does not exist.

Of course because the Apache, IIS, Nginx and lighttpd recognize all HTTP methods does not mean that web browsers will support them for use with things like HTML.

There may also be cases that the server accepts an "invented" method, but this you can (and should) handle in the application, understand that an HTTP method does not work "by magic" (automatically), it is just a dialog for you or your application behind the HTTP server (apache, etc.) make use of this "verb" (verb actually is the whole input, method is the GET, POST, DELETE, etc), is how you tell someone VOU na padaria, of course the answer coming to your application you can interpret the "VOU" as anything (not that this is correct), the idea of the methods is to standardize/organize the input data so that the server and the application (being Python, PHP, Asp.net, etc.) understand what you "intention", but it doesn’t mean that in fact you sent what you said you’d be doing.

I believe that it is not the HTTP server that does the "parse" of the data, but rather the application or framework that runs by the defined module or maybe even the module itself does this, of course this can vary, even if the method is implemented it must follow the very purpose, if it is not supported it is very likely to be an older server (it is not something impossible to find) however it is important to understand that in cases like POST it can receive different types of payload, part can be done on the front end and another part is resolved on the back end:

• application/x-www-form-urlencoded this is the default value

• multipart/form-data

• "Untreated", the way it was sent is delivered (unless it is a web browser)

And in the case of POST each shall be adjusted in accordance with Content-Type requisition

Controlling the accepted methods in Apache

In Apache2.2+ there is the <Limit> which can control the accepted methods and can be configured in all contexts (Apache settings or .htaccess), something like:

<Limit POST PUT DELETE>
    ... Instrução ...
</Limit>

Or use the LimitExcept which does the opposite, "protects" all but the defined:

<LimitExcept GET HEAD>
    ... Instrução se não for GET e HEAD ...
</LimitExcept>

An example as the documentation is to "protect" the methods (other methods will be "unprotected"):

<Limit POST PUT DELETE>
Require "usuário valido"
</Limit>

In Apache2.4 is has a module that you can activate called https://httpd.apache.org/docs/2.4/mod/mod_allowmethods.html (Experimental), in which you can define the only allowed methods (works in the context of directory):

<Location "/">
   AllowMethods GET POST OPTIONS
</Location>

Controlling the methods in Nginx

In Nginx you can do something similar to Apache kind of manually:

//Ignora o método POST e emite 405
if ($request_method = POST) {
    return 405;
}

I will edit to provide more details as possible