W3C home > Mailing lists > Public > public-appformats@w3.org > January 2008

Re: ISSUE-18: Is JSONRequest an acceptable alternative to the current model? [Access Control]

From: Jon Ferraiolo <jferrai@us.ibm.com>
Date: Fri, 4 Jan 2008 10:15:32 -0800
To: Web Application Formats Working Group WG <public-appformats@w3.org>
Message-ID: <OF614BCB50.6345EA3E-ON882573C6.006375D0-882573C6.00644C94@us.ibm.com>
Hi Art,
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? Anne dismissed my question on the issue,
and subsequently a couple of members of OpenAjax (including Microsoft,
including discussion with IE team) responded that it would be better to
only support HEAD and not support GET. Here is what Bertrand Le Roy of
Microsoft said in an email:
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.
Manos Batsis of the Sarissa toolkit responded +1 to the first paragraph

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:

   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.

Based on what Kris says above, it seems to me that both HEAD and GET need
to be supported in order to comply with the HTTP spec.


             Web Application                                               
             Formats Working                                               
             Group Issue                                                To 
             Tracker                   public-appformats@w3.org            
             <sysbot+tracker@w                                          cc 
             Sent by:                                              Subject 
             public-appformats         ISSUE-18: Is JSONRequest an         
             -request@w3.org           acceptable alternative to the       
                                       current model?  [Access Control]    
             01/04/2008 04:57                                              
             Please respond to                                             
              Web Application                                              
              Formats Working                                              
                 Group WG                                                  

ISSUE-18: Is JSONRequest an acceptable alternative to the current model?
[Access Control]


Raised by: Arthur Barstow
On product: Access Control

Doug Crockford raised this issue on 2008-01-02 via:


See also the follow-ups to Doug's e-mail, including but not necessarily
limited to:


(image/gif attachment: graycol.gif)

(image/gif attachment: pic08874.gif)

(image/gif attachment: ecblank.gif)

Received on Friday, 4 January 2008 18:17:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:21 UTC