What's the difference between HttpMethod and RequestType of HttpRequest?

The HttpRequest class defines two properties:

HttpMethod:

Gets the HTTP data transfer method (such as GET, POST, or HEAD) used by the client.

public string HttpMethod { get; }  

The HTTP data transfer method used by the client.

and RequestType:

Gets or sets the HTTP data transfer method (GET or POST) used by the client.

public string RequestType { get; set; }

A string representing the HTTP invocation type sent by the client.

What is the difference between these two properties? When would I want to use one over the other? Which is the proper one to inspect to see what data transfer method was used by the client?

The documentation indicates that HttpMethod will return whatever verb was used:

such as GET, POST, or HEAD

while the documentation on RequestType seems to indicate only one of two possible values:

GET or POST

I tested with a random sampling of verbs, and both properties seem to support all verbs, and both return the same values:

Testing:

Clien开发者_运维问答t Used    HttpMethod    RequestType
GET            GET           GET
POST           POST          POST
HEAD           HEAD          HEAD
CONNECT        CONNECT       CONNECT
MKCOL          MKCOL         MKCOL
PUT            PUT           PUT
FOOTEST        FOOTEST       FOOTEST

What is the difference between:

• HttpRequest.HttpMethod
• HttpRequest.RequestType

and when should I use one over the other?

Reflector shows that RequestType calls HttpMethod internally. So you're ever so slightly better off calling HttpMethod. Actually I think the real reason RequestType exists was for backwards compatibility with classic ASP.

You can check below article:-

Request methods: An HTTP request made using telnet. The request, response headers and response body are highlighted.

HTTP defines eight methods (sometimes referred to as "verbs") indicating the desired action to be performed on the identified resource. What this resource represents, whether pre-existing data or data that is generated dynamically, depends on the implementation of the server. Often, the resource corresponds to a file or the output of an executable residing on the server.

HEAD Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.

GET Requests a representation of the specified resource. Note that GET should not be used for operations that cause side-effects, such as using it for taking actions in web applications. One reason for this is that GET may be used arbitrarily by robots or crawlers, which should not need to consider the side effects that a request should cause. See safe methods below.

POST Submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both. PUT Uploads a representation of the specified resource. DELETE Deletes the specified resource. TRACE Echoes back the received request, so that a client can see what intermediate servers are adding or changing in the request. OPTIONS Returns the HTTP methods that the server supports for specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource. CONNECT Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy.[5] PATCH Is used to apply partial modifications to a resource.[6]

HTTP servers are required to implement at least the GET and HEAD methods[7] and, whenever possible, also the OPTIONS method.[citation needed] Safe methods

Some methods (for example, HEAD, GET, OPTIONS and TRACE) are defined as safe, which means they are intended only for information retrieval and should not change the state of the server. In other words, they should not have side effects, beyond relatively harmless effects such as logging, caching, the serving of banner advertisements or incrementing a web counter. Making arbitrary GET requests without regard to the context of the application's state should therefore be considered safe.

By contrast, methods such as POST, PUT and DELETE are intended for actions which may cause side effects either on the server, or external side effects such as financial transactions or transmission of email. Such methods are therefore not usually used by conforming web robots or web crawlers, which tend to make requests without regard to context or consequences.

Despite the prescribed safety of GET requests, in practice their handling by the server is not technically limited in any way, and careless or deliberate programming can just as easily (or more easily, due to lack of user agent precautions) cause non-trivial changes on the server. This is discouraged, because it can cause problems for Web caching, search engines and other automated agents, which can make unintended changes on the server.