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

Question

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

Navigation

#1 by (5 votes)

10

In a recent lecture, one of the speakers commented that the only methods that the APACHE and the NGINX accept / support are the 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, that is, 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 was actually sent.

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

http apache nginx webserver

asked by anonymous 04.07.2017 / 20:41

1 answer

QVideoWidget does not display anything Currency formatting to save in the database as DECIMAL

score 5 · Accepted Answer

They are, even by IIS, unless your HTTP server is out of date (depending on the type of server it uses it will issue an HTTP error, method that does not exist.

Of course, because Apache , IIS , Nginx and lighttPD recognize all HTTP methods do not want say that web browsers will support them for use with things like HTML.

There may also be cases where 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 that you or your application behind the HTTP server (apache, etc) make use of this "verb" (verb is actually the whole input, method is GET , POST , DELETE , etc), it is as you say to someone VOU na padaria , of course the answer coming to your application you can interpret " 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 (such as Python, PHP, asp.net, etc) understand what you "want", but that does not mean that you actually submitted what you said you would be doing.

I believe that it is not the HTTP server that parses 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 vary, even if the method is implemented it should follow the 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

And in the case of POST each is set according to Content-Type requisition

Controlling Accepted Methods in Apache

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

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

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

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

An example of 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 a module that you can activate called link ( Experimental ), where you can define the only permissible methods (works in the context of directory ):

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

Controlling Methods in Nginx

In Nginx you can do something similar to Apache rather than manually:

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

I'll edit to provide more details as possible