Introduction

When you work with older .NET web APIs, it is easy to assume there must be one official place that defines HTTP verb constants. The answer depends on which API you are using: HttpRequest.RequestType is just a string in classic ASP.NET, while WebRequest.Method is also a string but .NET ships helper constants for several protocol-specific request methods.

What HttpRequest.RequestType Actually Returns

In classic ASP.NET, HttpRequest.RequestType exposes the incoming HTTP method as text such as GET, POST, or PUT. There is no matching HttpRequest constants class that you import and compare against. The value is simply a string.

That means code like this is normal:

1using System;
2using System.Web;
3
4public class SampleHandler : IHttpHandler
5{
6    public void ProcessRequest(HttpContext context)
7    {
8        if (string.Equals(context.Request.RequestType, "POST", StringComparison.OrdinalIgnoreCase))
9        {
10            context.Response.Write("Handled a POST request.");
11            return;
12        }
13
14        context.Response.StatusCode = 405;
15        context.Response.Write("Method not allowed.");
16    }
17
18    public bool IsReusable => false;
19}

If you want constants here, you define them yourself or wrap the logic behind a helper method. In ASP.NET Core, the equivalent modern helper is Microsoft.AspNetCore.Http.HttpMethods.

Constants For WebRequest.Method

WebRequest.Method is also a string property, but the framework includes protocol-specific constants in WebRequestMethods. For HTTP, use WebRequestMethods.Http.

1using System;
2using System.Net;
3
4public static class WebRequestExample
5{
6    public static WebResponse SendHeadRequest(Uri uri)
7    {
8        var request = WebRequest.Create(uri);
9        request.Method = WebRequestMethods.Http.Head;
10        return request.GetResponse();
11    }
12}

The most common constants are:

• 'WebRequestMethods.Http.Get'
• 'WebRequestMethods.Http.Post'
• 'WebRequestMethods.Http.Put'
• 'WebRequestMethods.Http.Delete'
• 'WebRequestMethods.Http.Head'

There are similar classes for FTP and file requests. So the short answer is: there is no HttpRequest.RequestType constants class, but there is a WebRequestMethods.Http class for many WebRequest.Method values.

Prefer Modern HTTP APIs In New Code

WebRequest is an older API and new .NET code usually uses HttpClient together with HttpMethod. If you are starting fresh, the modern version is clearer and easier to test.

1using System.Net.Http;
2using System.Net.Http.Json;
3using System.Threading.Tasks;
4
5public static class HttpClientExample
6{
7    public static async Task<HttpResponseMessage> SendAsync(HttpClient client)
8    {
9        var request = new HttpRequestMessage(HttpMethod.Post, "https://api.example.com/items")
10        {
11            Content = JsonContent.Create(new { name = "demo" })
12        };
13
14        return await client.SendAsync(request);
15    }
16}

Notice the difference:

• 'HttpMethod.Get, HttpMethod.Post, and friends belong to System.Net.Http'
• 'WebRequestMethods.Http.Get belongs to the older System.Net stack'
• 'HttpRequest.RequestType in classic ASP.NET remains a plain string'

Knowing which layer you are in avoids a lot of confusion when IntelliSense does not show the constant you expected.

Creating Your Own Shared Constants

If you maintain classic ASP.NET code and dislike magic strings, define a small helper:

1public static class HttpVerbNames
2{
3    public const string Get = "GET";
4    public const string Post = "POST";
5    public const string Put = "PUT";
6    public const string Delete = "DELETE";
7}

Then compare against HttpVerbNames.Post instead of scattering raw string literals through the project. That does not change runtime behavior, but it improves consistency and reduces typos.

Common Pitfalls

The biggest mistake is looking for HttpRequest.RequestType.Get or a similar member on HttpRequest. No such constants exist there.

Another common issue is mixing classic ASP.NET APIs with ASP.NET Core examples. HttpMethods.Get exists in the newer stack, not in the old System.Web request model.

Developers also often assume WebRequestMethods.Http covers every custom verb. For less common verbs, you may still need to assign a string manually.

Finally, WebRequest itself is a legacy API. In new code, HttpClient and HttpMethod are usually the better design choice.

Summary

• 'HttpRequest.RequestType in classic ASP.NET is a plain string, not an enum or constants class.'
• 'WebRequest.Method is also a string, but .NET provides helpers such as WebRequestMethods.Http.Get.'
• Newer .NET applications should generally use HttpClient and HttpMethod.
• If you want verb constants in older code, create a small shared helper and keep comparisons consistent.