Charles McCathieNevile schrieb:
POST could be used to do so, but there is nothing in its defined
semantics that forces it to be used like that. POST hands the body to
something and says "do with this as you see fit", PUT says "begone, this
is your replacement".
Well. A server may replace a resource based upon POST. Another server
may reject PUT with 501.
The client doesn't know in advance. Nor do the authors of this
specification.
We can provide a list of verbs that MUST be supported, and say that
implementations should allow other verbs, but note for authors
thatimplementations may not, for example due to security concerns.
Well, that's the point I violently disagree with. By disallowing
"unknown" methods, this spec would be profiling HTTP and thus
restricting what other standards bodies can do. As far as I am
concerned, this is something this WG clearly shouldn't do.
Ah. We are violently agreeing. By saying that certain methods MUST be
supported, and others SHOULD (but MAY NOT) all methods are legal,
although authors are warned that relying on new methods working in all
systems is not necessarily the smartest thing to do - they should know
whether the system supports their method.
That's fine with me. Thus, we need the "SHOULD" for the methods not
listed as "MUST", and it should also be discussed when it's appropriate
not to support a specific method.
Finally, a user of the XHR MUST (!!!) be able to detect that an XHR
implementation indeed did not support a method (thus silent mapping to
GET is a severe bug!).
So what would be the recommended spec text then (yes, I know, I'm
supposed to make a proposal myself...).
Suggestion:
Implementations MUST support the methods GET, PUT, POST, DELETE, HEAD,
FooBar, Barfoo, BuyMeABeer, etc. Other methods SHOULD be supported,
allowing headers and a body to be sent and received. Authors are advised
that for security or other reasons, some implementations MAY NOT support
methods beyond those given in the list above.
Nit: "MAY NOT" isn't an RFC2119 keyword. Essentially MAY and MAY not
mean the same thing :-)
(The list of must-support methods is up for argument, I suppose,
although I believe we can (and am sure we should) get consensus on it
relatively fast).
Minimally, it should include all methods defined in IETF standards
tracks documents.
Best regards, Julian
