Re: GET vs HEAD vs OPTIONS

On Thu, 03 Jan 2008 23:51:35 +0100, Jon Ferraiolo <jferrai@us.ibm.com>  
wrote:
> Yes, I remember that part of the email discussion. Therefore, you support
> GET. By why not also support HEAD and OPTIONS? Why make everyone use the
> (arguably) wrong approach to HTTP just because some existing server
> technologies don't support all HTTP options conveniently at this  
> particular moment in time? We shouldn't confuse today's existing common  
> practice with future recommended best practice, and we shouldn't prevent  
> adoption of best practice techniques.

I tried to mention that in the next paragraph to which you did not reply  
at all. Let me try again:

1) There's no advantage in allowing multiple ways of doing this given that  
everybody will have to support GET as that will be what is used.

2) HEAD and OPTIONS don't see <?access-control?> processing instructions  
which makes the protocol less consistent which seems like a very bad  
thing. Especially with security related matters.

3) Depending on how this is done user agents might do different things and  
end up with different access policies for the same site. Which seems  
really bad.

4) Allowing multiple ways of doing the same thing just makes things more  
complex. The implementation. The testing of the implementation. The  
documentation. The specification. The test suite. Reviewing all that, et  
cetera. This seems like a bad thing.


>> GET also allows for taking the entity body into account in case of
>> XML files. Given that we need GET I'm not sure what use it would be to
>> allow OPTIONS in addition. There are after all (obvious) downsides to
>> such an approach such as the OPTIONS way giving a different response  
>> and some
>> user agents following the OPTIONS route and some others the GET, etc.
>> Seems messy.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Thursday, 3 January 2008 22:59:55 UTC