"Anne van Kesteren" <[EMAIL PROTECTED]>
On Sun, 14 May 2006 13:59:34 +0200, Jim Ley <[EMAIL PROTECTED]> wrote:
There are currently some methods that can't be allowed for security
reasons and because such method smay be introduced in the future as
well allowing arbitrary method names does not seem like a good idea.
I think you need to list these methods that cannot be used for security
reasons, to explain more of the motivations for this decision. It also
appears to be a direct reversal of the decision at the previous f2f
(issue 74) It would be good to see what had changed in between to
motivate the change, as there was no public discussion, other than more
support for having any verb.
I'm just stating the resolutions as they have been made here.
Sure, but if the groups aim is to work in public, then it needs to work in
public, ie provide the motivations for the decisions, and not just the
decisions, otherwise exactly what happens here happens and all we get is
discussion on the public list that exactly reflects the existing discussions
already had at a f2f or in a telcon etc. Which wastes everyones time. Just
reporting decisions is unhelpful, especially when they reverse previous
public decisions of the group.
What was raised against that is that it hurts adoption of new HTTP
methods. That's true for all other types of APIs as well though. Internet
Explorer 7 as opposed to Internet Explorer 6 uses a whitelist and other
browsers vendors are planning to do the same thing. The whitelist would
contain all "safe methods" currently spreaded over various RFCs.
I assume the whitelist is a SHOULD requirement - a MUST requirement would be
absolutely wrong as it prevents user agents from denying them for security
reasons.
Cheers,
Jim.
