Supporting "Differently Abled" Clients and Servers
While pretty much any modern client has access to a socket library and can pretty much construct any request in such a manner, a number of programming languages have higher level interfaces which take care of a number of administrative functions such as redirect, proxy support, and the like. Examples of such libraries: Python's urllib2 and JavaScript/VBScript/JScript's XMLHttpRequest. Unfortunately, many of these higher level libraries are limited what they support. Even the relatively recently issued XForms 1.0 Proposed Recommendation does not provide support for the DELETE method.
Server limitations are much more problematic. With most server setups, by the time an application gets access to the socket data, the HTTP method and headers have already been processed. A particularly problematic instance of this is where Apache by default strips off Authentication headers before invoking a CGI, presumably for security concerns. This makes implementing the proper Authorization headers a bit problematic.
So, given this, what is described below is a minimum set of requirements for both clients and servers. As limitations on one side imply requirements on the other side, these need to be explored together.
Overall the approach being explored is not to seek a least common demonimator. Those that support things like HTTP Digest and the full range of HTTP verbs are encouraged to do so. What is explored below is an approach that requires minimial changes for adapting to "differently abled" servers and clients.
A second order motivation is to exploit existing standards whenever possible. Note: the solution below is based on permitting SOAP clients. Similar support could be speced out for XML-RPC clients.
Limitations
Server
To date, the only server limitation that we have encountered is the one on the Authentication header. The solution is to propose a header with a new name that can be accepted by servers.
Client
While the set of potential servers seems to be relatively small and knowable, the set of potential clients seems unbounded. This argues for a much lower bar being set for clients. HTTP GET is pretty much a given. Being able to POST XML seems to be reasonable. Other combinations of HTTP methods and headers may or may not be acheivable.
Requirements
Servers
-
All servers MUST accept GET, PUT, POST, and DELETE methods. Other WEBDav methods (such as PROPFind and PROPPatch are under consideration, and this list will be updated should they be included.
-
All servers SHOULD support the X-WSSE header.
This would be expressed as a MUST except for the fact that security is a matter of policy. Of course, servers that wish to support standard HTTP authorizations schemes are encouraged to do so.
-
All servers MUST support the limited use of the SOAPAction HTTP Header as described below in the Client section.
-
And servers MUST be able to produce codes of 200 (success), 201 (created), 301 (moved), 401 (unauthorized), 403 (forbidden), and 410 (gone) status codes.
-
All servers MUST be able to process well formed XML. Servers need not be able to handle processing instructions or DTDs.
-
Servers must accept content in a SOAP Envelope, and if so they must wrap their responses in SOAP envelopes or produce a SOAP Fault per the example below.
Client
-
Clients SHOULD use the appropriate HTTP Method when possible. When not possible, they should use POST and include a SOAPAction HTTP header which is constrained as follows:
SOAPAction: "http://schemas.xmlsoap.org/wsdl/http/<METHOD>"
Where <METHOD> is replaced by the desired HTTP Method.
-
Clients MAY wrap their XML payload in a SOAP Envelope. If so, they must also wrap it in an element which exactly matches the HTTP Method. This requirement may be made clearer by looking at the examples below.
-
Clients MAY provide Web Services Security Username Token authentication per the Profile.
Examples
Request
Canonical
Note: the X-WSSE header has been split across lines for readibility
DELETE /path/page.html HTTP/1.0 Host: example.com X-WSSE: UsernameToken Username="USERNAME", PasswordDigest="PASSWORDDIGEST", Nonce="NONCE", Created="2003-09-08T05:52:36Z"
Alternate
POST /path/path.html HTTP/1.0 Content-type: text/xml Host: example.com SOAPAction: "http://schemas.xmlsoap.org/wsdl/http/DELETE" <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext"> <soap:Header> <wsse:Security> <wsse:UsernameToken> <wsse:Username>USERNAME</wsse:Username> <wsse:Password Type="wsse:PasswordDigest">PASSWORDDIGEST</wsse:Password> <wsse:Nonce>NONCE</wsse:Nonce> <wsu:Created>2003-09-08T05:52:36Z</wsu:Created> </wsse:UsernameToken> </wsse:Security> </soap:Header> <soap:Body> <DELETE xmlns="http://schemas.xmlsoap.org/wsdl/http/"/> </soap:Body> </soap:Envelope>
Successful Response
Canonical
HTTP/1.1 200 OK
Alternate
HTTP/1.1 200 OK Content-Type: text/xml <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body/> </soap:Envelope>
Failure Response
Canonical
HTTP/1.1 410 Gone
Alternate
HTTP/1.1 500 Failure Content-Type: text/xml <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>410</faultcode> <faultstring>Gone</faultstring> </soap:Fault> </soap:Body> </soap:Envelope>
[HenriSivonen] I think having TooManyAlternatives is a problem, because implementors would subset the spec on their own.