GET / HEAD / OPTIONS

On Fri, 04 Jan 2008 19:15:32 +0100, Jon Ferraiolo <jferrai@us.ibm.com>  
wrote:
> Could you please consider adding a new issue about the use of GET vs HEAD
> vs OPTIONS in order to retrieve from the server whether it is allowed to
> issue POST and DELETE requests?

The WG already discussed this issue extensively. It always came down to  
GET.


> Anne dismissed my question on the issue,

And you failed to address my remarks, repeatedly.


> [...] Here is what Bertrand Le Roy of
> Microsoft said in an email:
> ---------------
> Can they cite which servers don’t support HEAD?

That's not the point. The point is that a HEAD request does not give you  
access to the response entity body and therefore you can't perform the  
check.


> I’d argue that it shouldn’t even be a choice but always use HEAD if the  
> purpose of the request is just to authorize or deny a request using  
> another verb.
> GET will potentially result in a very large response, of which only the
> headers will be used. As for your objection about using a token, that  
> token can be in headers, which will also be sent when using HEAD.

One of our requirements is that you can simply put a file on the server  
and have it work. Also in the case where you can't configure HTTP headers.  
The protocol should also work consistently which is why GET is also used  
for the authorization request so the entity body is taken into account  
there as well. Given that servers opt-in to all of this and sites are  
unlikely to just make random cross-site requests it is unlikely you get a  
very large response.


> Kris Zyp said:
> ------------------
> For HEAD to behave differently than GET (except in providing a content
> body), is actually a violation of the HTTP spec, especially in regard to
> headers. Here is the description of HEAD from the HTTP spec:

This is not just about headers.


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

Received on Friday, 4 January 2008 18:52:23 UTC