On Thu, 08 Jun 2006 09:41:39 +1000, Ian Hickson <[EMAIL PROTECTED]> wrote:
On Wed, 7 Jun 2006, Mark Nottingham wrote:
Blindly standardising what one vendor does doesn't make sense; do you
know *why* they consider it a security feature?
The reputed security problems with various HTTP methods have been
brought up many times, but I have yet to see an explanation of how they
actually cause a security issue greater than supporting POST does.
Beyond curiosity, does it matter why? There's no point us publishing a
spec that contradicts Microsoft's implementation if Microsoft's
implementation is not going to change (which it isn't, if the reason for
it being the way it is is Security).
It's true that it makes no sense to standardise something that isn't going
to get implemented. Opera are also concerned that there may be security
implications in allowing any random verb.
We can provide a list of verbs that MUST be supported, and say that
implementations should allow other verbs, (that's something that should be
in extensibility anywa, and we will probably get comments from Karl Dubost
or W3C QA), but note for authors that implementations may not do this, for
example due to security concerns.
This allows for implementations that restrict the set of available verbs,
and also allows development that remains conformant with the
specification. From time to time there are new verbs that people like, and
even if not every implementation offers them, their development is a Good
Thing™...
Besides, I am with Mark on the principle that standardising things based
on security is generally something this group should not do. There are
many different security models and approaches on the web, and in order to
make documents that are usable in implmentations it is helpful to allow
for this, where possible.
Since security will virtually always trump standards conformance for
implementors (there are use cases for providing insecure systems too),
when we choose how to standardise current practice we should be wary of
following restrictions imposed for security over openness desired for some
use cases.
Trading off too much functionality for totally compatible interoperability
eventually comes at the cost of assuming no new development or innovation,
which would be a bad thing (and symbolic of a struggle against reality -
developers *will* innovate). That said, this is something that generally
comes to a case-by-case analysis of the particular problem...
cheers
Chaals
--
Charles McCathieNevile [EMAIL PROTECTED]
hablo español - je parle français - jeg lærer norsk
Peek into the kitchen: http://snapshot.opera.com/
