HttpRequest的HttpMethod和RequestType有什么区别？

Question

HttpRequest 类定义了两个属性：

< a href="http://msdn.microsoft.com/en-us/library/system.web.httprequest.httpmethod.aspx" rel="noreferrer">HttpMethod：

获取客户端使用的HTTP数据传输方法（例如GET、POST或HEAD）。

public string HttpMethod { get; }  

客户端使用的HTTP数据传输方式。

和 RequestType :

获取或设置客户端使用的HTTP数据传输方法（GET或POST）。

公共字符串RequestType { get;放; }

表示客户端发送的 HTTP 调用类型的字符串。

这两个属性有什么区别？我什么时候想使用其中一种而不是另一种？哪个是正确的检查方式以了解客户端使用了哪种数据传输方法？

文档表明 HttpMethod 将返回使用的任何动词：

例如 GET、POST 或 HEAD

，而有关 RequestType 的文档似乎仅指示两个可能值之一：

获取或发布

---

测试，这两个属性似乎都支持所有动词，并且都返回相同的值：

测试：

Client Used    HttpMethod    RequestType
GET            GET           GET
POST           POST          POST
HEAD           HEAD          HEAD
CONNECT        CONNECT       CONNECT
MKCOL          MKCOL         MKCOL
PUT            PUT           PUT
FOOTEST        FOOTEST       FOOTEST

之间有什么区别

• HttpRequest.HttpMethod
• HttpRequest.RequestType

以及何时应该使用一个其他？

Answer 1

Reflector 显示 RequestType 调用 HttpMethod内部。因此，调用 HttpMethod 会稍微更好一些。实际上，我认为 RequestType 存在的真正原因是为了向后兼容经典 ASP。

Answer 2

您可以查看以下文章：-

请求方法：
使用 telnet 发出的 HTTP 请求。请求、响应标头和响应正文突出显示。

HTTP 定义了八种方法（有时称为“动词”），指示要对所识别的资源执行的所需操作。该资源代表什么，无论是预先存在的数据还是动态生成的数据，取决于服务器的实现。通常，资源对应于驻留在服务器上的文件或可执行文件的输出。

头
请求与 GET 请求对应的响应相同的响应，但没有响应正文。这对于检索响应标头中写入的元信息非常有用，而无需传输整个内容。

得到
请求指定资源的表示。请注意，GET 不应用于会产生副作用的操作，例如使用它在 Web 应用程序中执行操作。原因之一是 GET 可能被机器人或爬虫任意使用，它们不应该考虑请求应引起的副作用。请参阅下面的安全方法。

邮政
将要处理的数据（例如，来自 HTML 表单）提交到所识别的资源。数据包含在请求正文中。这可能会导致创建新资源或更新现有资源或两者兼而有之。
放
上传指定资源的表示。
删除
删除指定的资源。
痕迹
回显收到的请求，以便客户端可以看到中间服务器在请求中添加或更改了哪些内容。
选项
返回服务器支持指定 URL 的 HTTP 方法。这可用于通过请求“*”而不是特定资源来检查 Web 服务器的功能。
连接
将请求连接转换为透明 TCP/IP 隧道，通常是为了通过未加密的 HTTP 代理进行 SSL 加密通信 (HTTPS)。 [5]
修补
用于对资源应用部分修改。[6]

HTTP 服务器需要至少实现 GET 和 HEAD 方法[7]，并且尽可能实现 OPTIONS 方法。[需要引用]
安全方法

某些方法（例如 HEAD、GET、OPTIONS 和 TRACE）被定义为安全的，这意味着它们仅用于信息检索，不应更改服务器的状态。换句话说，除了相对无害的影响（例如日志记录、缓存、横幅广告服务或增加网络计数器）之外，它们不应该有副作用。因此，在不考虑应用程序状态上下文的情况下发出任意 GET 请求应该被认为是安全的。

相比之下，诸如 POST、PUT 和 DELETE 之类的方法适用于可能对服务器造成副作用或外部副作用（例如金融交易或电子邮件传输）的操作。因此，此类方法通常不被符合要求的网络机器人或网络爬虫使用，它们倾向于在不考虑上下文或后果的情况下提出请求。

尽管规定了 GET 请求的安全性，但实际上服务器对它们的处理在技术上不受任何方式的限制，并且粗心或故意的编程也很容易（或更容易，由于缺乏用户代理预防措施）导致不平凡的更改在服务器上。不鼓励这样做，因为它可能会导致 Web 缓存、搜索引擎和其他自动化代理出现问题，从而可能对服务器进行意外更改。