Subject: Is OPTIONS Safe?

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Jun 2009 11:19:19 +1000

p2 7.2 currently says about OPTIONS:
> This method allows the client to
>    determine the options and/or requirements associated with a  
> resource,
>    or the capabilities of a server, without implying a resource action
>    or initiating a resource retrieval.
That sounds safe to me, but I don't see anywhere where this is said  
explicitly.

The answer matters for things like redirection without user  
intervention (assuming we keep that requirement).

Proposal: Specify that OPTIONS is safe.

Cheers,

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

---

From: John Kemp <[email-masked]>
Date: Tue, 02 Jun 2009 21:33:59 -0400

Mark Nottingham wrote:
>>    determine the options and/or requirements associated with a resource,
> That sounds safe to me,

 From p2 7.1.1:

"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.

> but I don't see anywhere where this is said 
> explicitly.

It seems to me that the definition of "safe" would then have to include 
operations which do not initiate a resource retrieval at all (eg. OPTIONS)

> 
> The answer matters for things like redirection without user intervention 
> (assuming we keep that requirement).
> 

By updating 7.1.1?

Regards,

- johnk

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Jun 2009 12:23:24 +1000

Yes, that's what I'm suggesting.

Cheers,

On 03/06/2009, at 11:33 AM, John Kemp wrote:

> Which suggests to me that "safe" currently means that _only_ a  
> retrieval operation takes place with safe methods.
>
>> but I don't see anywhere where this is said explicitly.
>
> It seems to me that the definition of "safe" would then have to  
> include operations which do not initiate a resource retrieval at all  
> (eg. OPTIONS)
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Jun 2009 07:28:19 +0200

> Yes, that's what I'm suggesting.

We already state that in Part 2, Section 10.1, but that is only the IANA 
registration 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-06.html#rfc.section.10.1>)...

So yes, the method description should state that as well.

What about TRACE then (which is the 4th candidate)?

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 Jun 2009 15:48:45 +1000

No real opinion. I suppose it is safe, in the sense that it doesn't  
change the state of the resource. Whether it should be automatically  
redirected isn't a terribly interesting question AFAICT, so I think it  
is...

http://trac.tools.ietf.org/wg/httpbis/trac/ticket/171

On 03/06/2009, at 3:28 PM, Julian Reschke wrote:

> We already state that in Part 2, Section 10.1, but that is only the  
> IANA registration (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-06.html#rfc.section.10.1 
> >)...
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 5 Jun 2009 10:31:32 +1000

Proposal:

Confirm both OPTIONS and TRACE as safe methods. Any objections?

On 04/06/2009, at 3:48 PM, Mark Nottingham wrote:

> redirected isn't a terribly interesting question AFAICT, so I think  
> it is...
>

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 13 Jun 2009 23:05:33 +1000

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.

On 05/06/2009, at 10:31 AM, Mark Nottingham wrote:

>> change the state of the resource. Whether it should be  
>> automatically redirected isn't a terribly interesting question  
>> AFAICT, so I think it is...
>>
>>> We already state that in Part 2, Section 10.1, but that is only  
>>> the IANA registration (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-06.html#rfc.section.10.1 
>>> >)...
>>>

---

From: Jamie Lokier <[email-masked]>
Date: Sat, 13 Jun 2009 17:06:58 +0100

> 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

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 15 Jun 2009 15:25:27 +0200

> What about TRACE then (which is the 4th candidate)?

+1

All methods which should not have any noticeable side effects is safe. 

TRACE by definition never should have side effects, nor should OPTIONS.

GET/HEAD should not have side effects, but often have anyway, but that's
besides the point. A server which barfs in some way if it gets the exact
same GET/HEAD request twice is technically not HTTP compliant, but in
reality nobody is going to care much about that.

Regards
Henrik