URI Proxy

Introduction

Using URIs as universal identifiers, and in a decentralized manner, can be a tricky proposition at times. While HTTP permits us to treat any Web server as a Web proxy of which I can ask for a representation of any URI (or otherwise interact with the identified resource), the practicalities of doing so aren't quite as simple. In particular;

• most Web servers can't be used as a Web proxy by developers, reducing the applicability of the pure HTTP proxying approach. i.e. a request for "http://www.yahoo.com" to an example.org-hosted HTTP server can't, in general, be dispatched to a Servlet, CGI, or the like
• there is no standard means of identifying a proxy

"URI Proxy" is an attempt to address these issues by using the the RDF Forms framework, to permit Web agents to dynamically discover and use a proxying service.

Example

<up:Proxy xmlns:rf="http://www.markbaker.ca/2003/rdfforms/"
             xmlns:up="http://www.markbaker.ca/2003/uriproxy/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             rdf:about="http://example.org/proxy/">
  <rf:indexedBy>
    <rf:IndexParam rf:shortName="uri">
      <rdf:predicate rdf:resource="http://www.w3.org/2001/XMLSchema#anyURI"/>
    </rf:IndexParam>
  </rf:indexedBy>
</up:Proxy>

This form is communicating the knowledge that the URI "http://example.org/proxy/" identifies a proxy service. The indexedBy block simply declares that the service is a GET based service (implicitly), and accepts a parameter of type URI (as defined by XML Schema) with a short name for the URI-encoding of "uri".

Given a URI to proxy for, for example "http://example.com/foo/bar/baz" then, the resulting URI per RDF Forms would be;

http://example.org/proxy/?uri=http://example.com/foo/bar/baz

Caution

The most important thing to note about this proxy model, when compared with the traditional proxy model, is that this one is gateway based and therefore has different end-to-end characteristics. For example, if content negotiation was used, the obligation is on the proxy service to satisfy that request, not the service being proxied for as it would be in the pure HTTP proxy case. In SOAP terms, the proxy service is the ultimate receiver of the message, and subsequent interaction with the service being proxied for (the "ultimate receiver" in the pure HTTP proxy case) involves an entirely new message.

It is strongly recommended that developers building URI proxies familiarize themselves with this subject.