Re: Is OPTIONS Safe?

John Kemp wrote:
> "In particular, the convention has been established that the GET and
>  HEAD methods SHOULD NOT have the significance of taking an action
>  other than retrieval.  These methods ought to be considered "safe".
>  This allows user agents to represent other methods, such as POST, PUT
>  and DELETE, in a special way, so that the user is made aware of the
>  fact that a possibly unsafe action is being requested."
> 
> Which suggests to me that "safe" currently means that _only_ a retrieval 
> operation takes place with safe methods.

In reality, GET is sometimes used for sending data across domains due
to the browser security model limiting POST, and is not necessarily
idempotent in such usages.

Hopefully OPTIONS will not fall into such dirty usage.

I have seen a few of HTTP server implementations where the method is
not checked properly (just checking for POST/HEAD) and therefore
OPTIONS would have the same effect as GET.  Clearly they are outside
the scope of the specifications.  But it does mean you can't rely on
OPTIONS behaving like OPTIONS universally, when implementing a client
which accesses arbitrary resources such as a spider.  For
user-specified resources it's probably a reasonable assumption.

-- Jamie

Received on Saturday, 13 June 2009 16:07:33 UTC