Subject: Re: Proposal: Is OPTIONS Safe? [#171]

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Jul 2009 16:39:34 +0200

Mark Nottingham wrote:
> No objections, and I note that 2616 already says in 9.1.2:
> 
> "Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and 
> so are inherently idempotent."
> 
> Julian, please go ahead.
> ...

OK, the simplest way to fix this is to add OPTIONS and TRACE to the 
enumeration in P2, 7.1.1, so that it becomes:

    In particular, the convention has been established that the GET,
    HEAD, OPTIONS, and TRACE 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.

(see 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/171/171.diff>).

An alternative requiring more work would be to add statements about 
safeness and idempotency to each method description.

In the absence of feedback I'll proceed with the simple solution soonish.

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 29 Jul 2009 18:09:37 +0200

I think it would be good to enumerate it in each method definition as  
well, to promote good practice in extension methods if nothing else.

On 27/07/2009, at 4:39 PM, Julian Reschke wrote:

>> "Also, the methods OPTIONS and TRACE SHOULD NOT have side effects,  
>> and so are inherently idempotent."
>> Julian, please go ahead.
>> ...
>
> (see <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/171/171.diff 
> >).
>

--
Mark Nottingham     http://www.mnot.net/

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 29 Jul 2009 18:26:39 +0200

>From my point of view being a proxy cache implementer a methods is
non-idempotent unless explicitly told otherwise.

But does not hurt having it clearly stated.

Regards
Henrik