[OpenAjaxSecurity] Fw: GET vs HEAD vs OPTIONS

Kris Zyp kriszyp at xucia.com
Fri Jan 4 10:23:11 PST 2008


I was just saying that it seems that the HTTP spec requires that if some
header based functionality (like Access-Control) is added to GET, it must
work the same way for HEAD, and vice versa. They should be identical except
for the delivery of the content body.
Kris

On Jan 4, 2008 10:52 AM, Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com>
wrote:

>  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.
>
> 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
>
>
>
> _______________________________________________
> 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/20080104/a6751eec/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/20080104/a6751eec/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/20080104/a6751eec/attachment-0001.png 


More information about the security mailing list