How do you extend the HTTP?

TAG,

I write to raise an issue that has wasted a large amount of my time in 
the past year, and causes confusion for any group attempting to design a 
protocol based on the HTTP. The specifications may be clear, but 
conventional wisdom is certainly muddled. There's a lot of overlap with 
the deferred HTTPSubstrate-16, but I feel that this issue needs to be 
addressed promptly.

"How do you extend the HTTP?"

In the Atom WG, I've heard arguments against using a "MOVE" method on 
the grounds that "Atom shouldn't need to extend HTTP". That's a 
reasonable argument, but I found it strange to hear from people who were 
advocating the use of extension headers. What leads to this definition 
of "extend"? It's very common.

A second issue that's arisen are HTTP implementations such as Macromedia 
Flash, Apple's NSURLConnection, and Python's urllib2 that don't support 
PUT, DELETE, or extension methods. The debate then becomes "HTTP is 
*really* just GET and POST. Look at NSURLConnection, see?". Moving 
further down, there are implementations that support GET, POST, and no 
extension headers.

In the web-arch press release, I read that the TAG is considering Web 
Services best practices as a possible issue. I believe that variance in 
HTTP implementations lies at the heart of many Web Services 
implementation decisions. The problem is not that some implementations 
are broken, but that there is no definition of "broken".

I see the logic in the points of view advanced in [1], [2], and [3] 
below. However, when taken together, they result in [4] (whose author is 
well-aware of the problem).

1.) http://www.w3.org/2002/ws/addr/5/02/28-ws-addr-minutes.html#TAG
    "I think there's a pretty square box around GET/PUT/POST/DELETE.
     there's a reason no others have been standardized."

2.) http://imc.org/atom-protocol/mail-archive/msg00644.html
    "HTTP, as deployed and used today, is pretty well a two-verb
     protocol."

3.) http://www.xent.com/FoRK-archive/feb98/0238.html
    "Gee, let's define a bunch of new HTTP methods. The current WebDAV
     draft follows this approach. This appears to be the best approach
     while staying within the current web framework."

4.) http://dehora.net/doc/httplr/draft-httplr-01.html#rfc.section.8.2
    "The Client MAY use one of PUT or POST to send its Message to the
     exchange URL..."

[3] best reflects my own thinking, but I'm most interested in reducing 
the quantity of mixed messages emanating from the W3C and elsewhere. At 
the very least, I want to stress that these issues are very unclear to 
most implementors and the TAG should consider that when drafting any 
future finding.

thank you for your time,

Robert Sayre

Received on Saturday, 19 March 2005 19:46:37 UTC