On Thu, 08 Jun 2006 23:54:53 +1000, Julian Reschke <[EMAIL PROTECTED]>
wrote:
... it exposes users to a potential security risk, and there's nothing
the user can do about it except disabling scripting. I think that is a
problem.
SURE. That doesn't make it a bug per se. It also exposes the user to a
bunch of functionality that they might appreciate. I thnk it's a decision
to implement or not that way, and to use a user agent that does that or
not. I would be surprised if desktop browsers for general release were so
permissive. But there are a wider range of user agents and use cases, even
among the manufacturers of desktop browsers.
RFC2616 calls it a convention, but also says
...
Naturally, it is not possible to ensure that the server does not
generate side-effects as a result of performing a GET request; in fact,
some dynamic resources consider that a feature. The important
distinction here is that the user did not request the side-effects, so
therefore cannot be held accountable for them.'
To the extent that RFC 2616 determines who is held accountable this is
true. But real use cases go far beyond the reach of RFCs.
If a server implements unsafe actions upon GET, that's a bug in the
server. For instance, should a GET request to a certain URL cause a
vendor to ship something to me (just because my user agent pre-caches
content linked from the current page), it's the vendor's problem, not
mine.
Assuming the vendor accepts RFC2616 as binding. If not, and the vendor has
your money, you know about possession being 9/10 and all that...
My basic position is that all these things should be noted for
information, because they are real implementation and use issues, that
affect interoperability of code in particular. But the spec should not say
which things are allowed or not based on our notion of appropriate
security - since implementors will ignore us if they decide they want to,
and we should not be randomly closing off things that have use cases
because we decide that some bad use case can be made too. In the first
instance that is the job of implementors, in the second it is a seperate
effort in standardisation which is somewhat orthogonal to our work of
specifyig the APIs that people use.
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/
