I've been reviewing the Access Control for Cross-site Requests document. One interesting aspect of the document is that it specifies how a web site can authorize other web sites to do non-GET operations such as PUT or DELETE. The client makes an authorization request by creating an HTTP GET with the http header Method-Check. The server then responds with an HTTP Response containing Access-Control HTTP Headers or even an XML document with Processing Instructions.
Now the part that I found very interesting is that it seems that the client's authorization request isn't really for the resource identified by the URI, because the goal is to actually get the authorization information. Thus, an HTTP GET has been over-ridden to be a GET of metadata about a resource. Also interestingly, if the URI for some reason doesn't know about the Method-Check header, then it will return the "wrong" representation, that is the actual representation. There is no way of requiring that the server knows about the Method-Check request.
Over in WS-* land, WS-ResourceTransfer is a specification that uses a SOAP header wsrt:ResourceTransfer to indicate that there may be RT specific extensions to the WS-Transfer operation, such as GET. Because it uses a SOAP header, it can use the soap:mustUnderstand attribute to require that the server understand it.
Seems to me like this is an interesting case of where SOAP solves a problem that the Access Control for Cross-site requests has, that is the ability to mark a header as mustUnderstand. This isn't surprising, given that SOAP was exactly created to solve problems with HTTP headers.