[OpenAjaxSecurity] Fw: GET vs HEAD vs OPTIONS

Bertrand Le Roy Bertrand.Le.Roy at microsoft.com
Fri Jan 4 09:52:04 PST 2008

Absolutely, but I don't see how HEAD would be behaving differently in that case. Can you elaborate on that?

From: security-bounces at openajax.org [mailto:security-bounces at openajax.org] On Behalf Of Kris Zyp
Sent: Thursday, January 03, 2008 6:31 PM
To: OpenAjax Alliance Security Task Force
Subject: Re: [OpenAjaxSecurity] Fw: GET vs HEAD vs OPTIONS

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:

   The HEAD method is identical to GET except that the server MUST NOT
   return a message-body in the response. The metainformation contained
   in the HTTP headers in response to a HEAD request SHOULD be identical
   to the information sent in response to a GET request. This method can
   be used for obtaining metainformation about the entity implied by the
   request without transferring the entity-body itself. This method is
   often used for testing hypertext links for validity, accessibility,
   and recent modification
OPTIONS is a little harder to pin down and could understandably be omitted.
On Jan 3, 2008 7:19 PM, Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com<mailto:Bertrand.Le.Roy at microsoft.com>> wrote:

Can they cite which servers don't support HEAD? 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.

This looks very wrong to me.

Oh, and on other news, the IE team has had some very limited involvement in this spec (several members of the team are in the acknowledgement section), and of course they know about it. They agree that HEAD should be used.

From: security-bounces at openajax.org<mailto:security-bounces at openajax.org> [mailto: security-bounces at openajax.org<mailto:security-bounces at openajax.org>] On Behalf Of Jon Ferraiolo
Sent: Thursday, January 03, 2008 6:08 PM
To: security at openajax.org<mailto:security at openajax.org>
Subject: [OpenAjaxSecurity] Fw: GET vs HEAD vs OPTIONS

Bertrand and everyone else,
Here is the response to my query about why Access Control only supports GET and does not support HEAD or OPTIONS. This response makes me a bit queasy because of the layers of design kludges in the (well-intentioned but potentially misguided) goal of working with existing servers.

Let's suppose an Ajax developer posts an application on www.example.com<http://www.example.com/> that wants to post some data to some other site, such as www.companion-site.com<http://www.companion-site.com/>, using JSON in both directions. The developers at www.example.com<http://www.example.com/> must ocde their JavaScript to check to make sure that the browser supports Access Control, and if so, generate an XHR GET to www.companion-site.com<http://www.companion-site.com/>, then subsequently generate an XHR POST to www.companion-site.com<http://www.companion-site.com/> (thereby counting on the *browser* [assuming it supports Access Control] to decide whether it is OK to issue a POST). In coordination with this, the developers at www.companion-site.com<http://www.companion-site.com/> must set a couple of custom HTTP headers in response to a GET to tell the browser that it is OK for www.example.com<http://www.example.com/> to issue a POST. If www-companion-site.com<http://www-companion-site.com/> is developed by security-conscious developers, to prevent CSRF, they will also include a unique token in the GET response which must be returned with the POST, and make sure that the developers at www.example.com<http://www.example.com/> know about sending the token back up with the POST request. That's a lot of effort and coordination to achieve something that will only work in some browsers for years to come, especially since there is already an option today to do the same thing today via a server proxy at www.example.com<http://www.example.com/>, and with OpenAjax Hub 1.1, you will be able to make it happen in a secure manner from the client.


----- Forwarded by Jon Ferraiolo/Menlo Park/IBM on 01/03/2008 05:47 PM -----

"Anne van Kesteren" <annevk at opera.com<mailto:annevk at opera.com>>

01/03/2008 03:02 PM


Jon Ferraiolo/Menlo Park/IBM at IBMUS


"WAF WG (public)" <public-appformats at w3.org<mailto:public-appformats at w3.org> >



On Thu, 03 Jan 2008 23:51:35 +0100, Jon Ferraiolo <jferrai at us.ibm.com<mailto:jferrai at us.ibm.com>>
> 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/>

security mailing list
security at openajax.org<mailto:security at openajax.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20080104/a96b4378/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 168 bytes
Desc: image001.png
Url : http://openajax.org/pipermail/security/attachments/20080104/a96b4378/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 166 bytes
Desc: image002.png
Url : http://openajax.org/pipermail/security/attachments/20080104/a96b4378/attachment-0003.png 

More information about the security mailing list