[OpenAjaxSecurity] Fw: GET vs HEAD vs OPTIONS

Jon Ferraiolo jferrai at us.ibm.com
Thu Jan 3 18:08:15 PST 2008



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
that wants to post some data to some other site, such as
www.companion-site.com, using JSON in both directions. The developers at
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, then subsequently generate an XHR POST to
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 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 to issue a POST. If 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 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, and with OpenAjax
Hub 1.1, you will be able to make it happen in a secure manner from the
client.

Jon


----- Forwarded by Jon Ferraiolo/Menlo Park/IBM on 01/03/2008 05:47 PM
-----
                                                                           
             "Anne van                                                     
             Kesteren"                                                     
             <annevk at opera.com                                          To 
             >                         Jon Ferraiolo/Menlo Park/IBM at IBMUS  
                                                                        cc 
             01/03/2008 03:02          "WAF WG (public)"                   
             PM                        <public-appformats at w3.org>          
                                                                   Subject 
                                       Re: GET vs HEAD vs OPTIONS          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




On Thu, 03 Jan 2008 23:51:35 +0100, Jon Ferraiolo <jferrai at 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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20080103/7299dbdc/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic12196.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20080103/7299dbdc/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20080103/7299dbdc/attachment-0001.gif 


More information about the security mailing list