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

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.

New methods should be added when an extension signifies a new type
of action (e.g., PATCH is better than PUT+Content-Range).  New status
codes should be added when the response enables automatic handling by
a client that is distinct from the existing codes.  If we let broken
implementations determine the meaning of HTTP, then HTTP will slowly
degrade as implementors make mistakes over time.

....Roy

Received on Tuesday, 7 August 2007 02:07:53 UTC