[OpenAjaxSecurity] Fw: GET vs HEAD vs OPTIONS

Kris Zyp kriszyp at xucia.com
Thu Jan 3 18:30:54 PST 2008


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.
Kris
On Jan 3, 2008 7:19 PM, Bertrand Le Roy <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] *On Behalf Of *Jon Ferraiolo
> *Sent:* Thursday, January 03, 2008 6:08 PM
> *To:* 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.comthat 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>*
>
> 01/03/2008 03:02 PM
>
> To
>
>
> Jon Ferraiolo/Menlo Park/IBM at IBMUS
>
> cc
>
>
> "WAF WG (public)" <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/>
>
> _______________________________________________
> security mailing list
> security at openajax.org
> http://openajax.org/mailman/listinfo/security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20080103/ee68013b/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 166 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20080103/ee68013b/attachment.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 168 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20080103/ee68013b/attachment-0001.png 


More information about the security mailing list