UserPreferences

DifferentlyAbledClients


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: [WWW]Python's urllib2 and [WWW]JavaScript/VBScript/JScript's XMLHttpRequest. Unfortunately, many of these higher level libraries are limited what they support. Even the relatively recently issued [WWW]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 [WWW]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 [WWW]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

Client

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.