At first glance, when one is writing a HTTP proxy, you would look up a relevant HTTP/1.1 RFC to learn about the various protocol methods that exist, such as GET and POST.

The first RFC you would find is RFC-2616, which contains the following list which is defined in section 5.1.1

• OPTIONS
• GET
• HEAD
• POST
• PUT
• DELETE
• TRACE
• CONNECT

That RFC refers to RFC-2068, which introduced the following HTTP methods:

• PATCH
• LINK
• UNLINK

The problem is they also allow an extension-method. Many existing filtering proxies do not handle anything other than the above methods. This causes problems with many applications and websites because they rely on extension methods to do their work.

Internet Filters however need to know all of the extension methods in use in order to make sense of the traffic going through the filter. Allowing unknown extension methods through could very well be a security hole or filter hole.

WebDAV HTTP Methods

One of the major extensions to HTTP/1.1 is WebDAV, which is defined in RFC-2518. WebDAV is used by multiple applications, such as file systems including Apple's iDisk and Microsoft Explorer's "Open as web folder" option, source control systems such as SVN, and even Microsoft Exchange makes e-mail folders accessible via WebDav.

WebDav extensions define the following additional HTTP methods:

• PROPFIND
• PROPPATCH
• MKCOL
• COPY
• MOVE
• LOCK
• UNLOCK

But that is not enough... There is a newer RFC that adds HTTP methods for WebDAV. It is RFC-3253. It defines the following additional methods:

• VERSION-CONTROL
• REPORT
• CHECKOUT
• CHECKIN
• UNCHECKOUT
• MKWORKSPACE
• UPDATE
• LABEL
• MERGE
• BASELINE-CONTROL
• MKACTIVITY

In RFC-3648, they added the following method:

• ORDERPATCH

And there is another RFC for WebDav, RFC-3744 Which adds the following:

• ACL

And that is still not enough... There is another RFC that adds even more HTTP methods for WebDAV. It is RFC-4437. It defines the following addition methods:

• MKREDIRECTREF
• UPDATEREDIRECTREF

We find that there is a newer RFC for WebDAV which obsoletes RFC 2518 - The new RFC is RFC-4918 - but it does not add any new methods.

One of the additional uses of WebDAV is for Calendaring - They call it CalDAV. Microsoft Outlook and other applications can use CalDAV to manage calendars. This is specified in RFC-4791 which adds the following method:

• MKCALENDAR

RFC-5323 extends WebDAV with one more additional method:

• SEARCH

The WebDAV protocol has been actively updated, and there are some IETF drafts that have not been made into RFC's yet, as of March 2009. One important one is called Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) and it defines the following methods:

• BIND
• UNBIND
• REBIND

Non-Standard HTTP Methods

Microsoft has a whole set of additional HTTP Methods which Microsoft Exchange uses. These are completely non-standard, but according to the HTTP specification, are allowed as extension-methods:

• BCOPY
• BDELETE
• BMOVE
• BPROPFIND
• BPROPPATCH
• NOTIFY
• POLL
• SUBSCRIBE
• UNSUBSCRIBE
• X-MS-ENUMATTS

The Complete List

So now, the complete list of known standard and non-standard HTTP methods is, in alphabetical order:

ACL BASELINE-CONTROL BCOPY BDELETE BIND BMOVE BPROPFIND BPROPPATCH CHECKIN CHECKOUT CONNECT COPY DELETE GET HEAD LABEL LINK LOCK MERGE MKACTIVITY MKCALENDAR MKCOL MKREDIRECTREF MKWORKSPACE MOVE NOTIFY OPTIONS ORDERPATCH PATCH POLL POST PROPFIND PROPPATCH PUT REBIND REPORT SEARCH SUBSCRIBE TRACE UNBIND UNCHECKOUT UNLINK UNLOCK UNSUBSCRIBE UPDATE UPDATEREDIRECTREF VERSION-CONTROL X-MS-ENUMATTS

The Problem

This whole state of affairs is quite unfortunate - The fundamental problem is that the HTTP protocol explicitly allows extension-methods and this leads programmers to think that it is a good idea to create their own HTTP method for a special purpose.

When you have your application talking directly to your server, this works just fine. But as soon as you need to have a third party intermediary parsing, modifying, filtering, and forwarding the protocol, every intermediary needs to understand your extensions.

For instance, if you decided to make a non-standard method called NOTIFY There is no guarantee that that eventually that specific method name would not be in a future HTTP WebDAV standard, specified in an incompatible way. Then it is your app which is non-standards compliant and any intermediary servers have the fun job of trying to figure out if the HTTP request it just received is a non-standard one or a standard one with the same name.

At least the X-MS-ENUMATTS verb is sensibly named, as the X-MS- prefix clearly defines it to be a Microsoft extension in its own namespace.

The IANA is planning to form a registry of HTTP Method Names (aka 'Verbs'); a Draft Document from September 2008 refers to a Method Registry at http://www.iana.org/assignments/http-methods but that does not exist as of March 2009 - but if and when it does exist it would probably not include third party made-up extension methods and their potential conflicts.

The reality is that the original HTTP methods (POST,GET,PUT,DELETE,HEAD,CONNECT,OPTIONS) are the only HTTP methods ever truly needed. Every other function that a HTTP server or web application ever needs to do could be expressed in terms of these methods - Even for WebDAV like functionality. See the details on RESTful design which builds upon the original ideas behind the HTTP protocol as a stateless, simple protocol.

Unfortunately, the reality is that the original, simple HTTP protocol got 'complexified' and this is why some applications become broken in the presence of a filtering proxy server.

Proxies that implement security features have no other option but to block unknown HTTP methods, for without the proxy understanding the HTTP method it can not deem it 'safe' or 'unsafe' to allow. Pushing the configuration of HTTP methods to the end user is pushing complexity to the end user or network administrator - who may be in a position where the same method should be allowed for one application and not allowed for a different application, or has no knowledge or can have no knowledge of the real purposes of the problem extension methods that a closed source application and server utilizes.

Adding HTTP extension methods is effectively changing the HTTP protocol. If you are a software programmer, think more than twice if you think you need to. How is your extension method going to be anything other than a Create, Read, Update, or Delete of some resource?

And PLEASE refrain from doing what WinAMP did with their Shoutcast protocol - Which looks like HTTP but is completely non-compliant with the HTTP standards and this causes many people a multitude of problems. They could have made their protocol do everything they needed with plain HTTP/1.1

Interestingly HTTP Verb Tampering can be a security hole on existing websites.

--jdkoftinoff