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

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

The Speaker further clarifies that when the other methods, such as PUT, PATCH, DELETE and others are used, the APACHE and the NGINX mask the method, that is, they 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, in fact was sent.

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

Author: LINQ, 2017-07-04

1 answers

Are yes, even by IIS, unless your HTTP server is outdated (be it an old version), depending on the type of server you use it will issue an HTTP error if you invent a method that does not exist.

Of course because 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 a "invented" method, but this you can (and should) deal with in the application, understand that an HTTP method does not work " by magic "(automatically), it is just a dialog so that you or that your application behind the HTTP server (apache, etc.) make use of this "verb" (verb is actually the whole input, method is the GET, POST, DELETE, etc), it's like 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 understand what you "intend" , but it does not mean that in fact you sent what you said you would 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 through the defined module or maybe even the module itself does this, of course this can if the method is implemented it must follow the scratch the purpose, if it is not supported it is quite likely that it is 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 made in the front-end and another part]}

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

  • multipart/form-data

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

And in the case of POST each is adjusted according to the Content-Type request

Controlling accepted methods in Apache

No Apache2.2 + exists or <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 that makes the otherwise, it "protects" all but those defined:

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

An example as per 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 os methods not Nginx

In Nginx you can do something similar to Apache sort 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

 5
Author: Guilherme Nascimento, 2017-07-04 20:46:58