Re: [access-control] non-GET threat model and authorization choreography

* Anne van Kesteren wrote:
>For a non-GET access request you look up in the access method check cache  
>whether you can make the desired non-GET to the URI. If the access method  
>check cache doesn't have an entry for the given URI you make an access  
>method check request to URI. An access method check request is a GET  
>request that includes a Method-Check HTTP header that indicates the  
>desired HTTP method. You do a match against the response Allow header  
>method list and if there's a match (case-sensitive comparison as per HTTP)  
>and the response also includes Access-Control / <?access-control?> stuff  
>that allows access you do a subsequent request to the URI with the non-GET  
>method.
>
>If the response to the access method check request also includes an  
>Method-Check-Expires HTTP header that is valid and contians an HTTP-date  
>later than now the user agent appends an entry to the access method check  
>cache for the URI with an expiry date as indicated by the  
>Method-Check-Expires header. This entry contains all the Access-Control /  
><?access-control?> / Allow / Method-Check-Expires information so requests  
>with a different Referer-Root can also benefit from it.

Could you say what essential parts of this protocol would break under
real world circumstances if clients would not send a Method-Name header,
would not send a Referer-Root header, would use OPTIONS instead of GET,
and consequently not check for processing instructions in the response,
and why the specification needs to address those cases, if any?
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Monday, 15 October 2007 17:35:57 UTC