Why HttpRequest.HttpMethod is string instead of Enum?

In the Reference of HttpRequest.HttpMethod of .NET Framework, request type is declared with System.String type.

In RFC 2616 all HTTP request methods are declared (e.g. POST, GET, PUT, DELETE...).

There's also similar behavior in HttpWebRequest and WebRequest classes of .NET.

Java has the similar approach on HttpUR开发者_运维技巧LConnection#setRequestMethod(String) method.

Why do these language designers do not consider implementing an enum for those HTTP methods?

Do you have an idea?

The first sentences of your RFC 2616 link (emphasis added):

The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded...

That is to say, the method in HTTP may be anything. There are "well known" or common methods, the semantics of which are well understood (well, okay, should be well understood - I still encounter people unclear on GET/POST).

But any application may implement other methods. Hopefully, the semantics of those other methods will be well understood between client and server applications.

For these reasons, an enum would be inappropriate, since there can always be "other" values that wouldn't fit in that enum.

More quotes from the RFC 2616:

Practical information systems require more functionality than simple retrieval, including search, front-end update, and annotation. HTTP allows an open-ended set of methods and headers that indicate the purpose of a request

and,

The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.

   Method         = "OPTIONS"                ; Section 9.2
                  | "GET"                    ; Section 9.3
                  | "HEAD"                   ; Section 9.4
                  | "POST"                   ; Section 9.5
                  | "PUT"                    ; Section 9.6
                  | "DELETE"                 ; Section 9.7
                  | "TRACE"                  ; Section 9.8
                  | "CONNECT"                ; Section 9.9
                  | extension-method
   extension-method = token

The spec explicitly allows for more methods to be used, and so the set of all methods cannot be enumerated.

if HTTP Comes with a new method, then java and C# needs to update their enum. When will they update it? Will they release a patch? or will be updated in next version? So defining a enum on values which they dont control is not a wise decision.

As Damien mentions, RFC2616 only defines the common methods. HTTP, like XML, is a protocol that can be extended to support other formats.

For instance, suppose I wanted to implement a special method called "Encrypt". If the HTTP library were enums, it would fail and likely throw an exception. Of course the client would have to know about this special request type, which is why most extensions are done via headers rather than commands.

HTTP is an extensible protocol, but few people actually do extend it.

Consider this simple example:

<form method="Foo" action="http://someurl"></form>

Since "method" is just text, and the user could put anything there, then the HTTP handler has to be able to handle it, correct?

EDIT:

As it turns out, the HTML 4 specification only allows for GET and POST to be valid values, but HTTP goes beyond that.