Re: New issue: Need for an HTTP request method registry

On Aug 6, 2007, at 7:07 PM, Roy T. Fielding wrote:

>
> On Aug 6, 2007, at 4:59 PM, Adrien de Croy wrote:
>> TCP flags IMO are akin to HTTP methods.  They define the set of  
>> states and state transitions etc.  TCP options are more akin to  
>> HTTP headers.  They are modifiers rather than definers of state  
>> (if that makes any sense).
>>
>> Adding methods and response codes to HTTP is like adding a new TCP  
>> flag.  Most people wouldn't even consider that an option, and  
>> wouldn't even start down that path.  It likely breaks any  
>> intermediaries as well as servers and clients
>>
>> Adding new headers is like adding a new option to TCP (like SACK  
>> etc).  That is a lot more approachable, but still highly  
>> significant and onerous.  It is normally a lot less likely to  
>> break existing infrastructure.
>>
>> Anyway, I guess not that useful a simile.  The point I was trying  
>> to make is we shouldn't be adding new methods and status codes  
>> unless there's absolutely no other way to do something, and that  
>> thing really needs to be done.  There's pretty much always another  
>> way.
>
> No, sorry, that is just wrong.  HTTP has been defined such that
> intermediaries do not need to know the meaning of methods, and hence
> can forward extension methods just as safely as they forward header
> fields.  The exception is when the intermediary is specifically
> configured to block unknown methods for local policy reasons, and it
> is for that reason that we *want* method-like extensions to be
> communicated as methods.  We want people to be able to control
> their own networks.
>
> If an intermediary is accidentally blocking unknown methods,
> then it is simply broken and should be replaced by something that
> actually implements HTTP.

+1.  I've never understood why, in the worst case, an intermediary  
couldn't have a configuration file or admin UI that allowed humans to  
add or remove whitelisted or blacklisted method names.  It seems  
extraordinarily backwards, especially nearly 10 years after WebDAV  
first appeared on the 'Net, to require software updates to handle new  
methods!

Lisa