Re: How do you extend the HTTP?

On Mar 19, 2005, at 21:33, ext Robert Sayre wrote:

>
> ... 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"?

One very important distinction between extending HTTP by new methods vs.
by new headers -- and one that is often overlooked or dismissed -- is 
how
either approach provides robustness.

The behavior of an HTTP server recieving a request using a method that
it does not support is quite clear and unambiguous -- the request fails.

However, for extension headers, included in a request using a 
standardized
method (e.g. GET); if the server (or component handler) does not 
recognize
and understand a given header, it can simply ignore it and proceed, and
thus, the client may recieve a result which it presumes takes into 
account
the specified header, but in fact does not.

Thus, each and every solution must encorporate machinery to verify
success or failure for each request -- something that should be provided
by the underlying protocol, i.e. HTTP. With new methods, it does.

 From a systems engineering standpoint, excluding (or discriminating
against) the use of new methods makes it harder to create robust web
applications.

Secondly, a frequent argument against new methods is concern for 
achieving
broad support for new functionality. Well, that argument is just as 
valid
for new headers. True, adding support for new headers is often easier 
than
adding support for new methods, but from a free-market viewpoint, if the
functionality provided by support for any particualar new methods is 
seen as
providing sufficient benefit, then it all just comes down to the 
economics
of supply and demand. If users demand that their web clients be able to
interact with web servers using those new methods, then web server 
owners
(and web server platform vendors) will respond proportionally to that 
demand.
I.e. it is not a technical or architectural issue, but a social/market 
issue.

Getting global buy-in and ubiquitous deployment of *any* new web
technology is hard. But the lion's share of that challenge has nothing
whatsoever to do with whether new methods vs. new headers are used.

(and IMO *both* are needed and have their proper use and purpose)

Cheers,

Patrick


--

Patrick Stickler
Senior Architect
Forum Nokia Online
Tampere, Finland
patrick.stickler@nokia.com

Received on Monday, 21 March 2005 08:39:52 UTC