RFC 2169 (rfc2169) - Page 3 of 9

A Trivial Convention for using HTTP in URN Resolution

RFC 2169                 HTTP in URN Resolution                June 1997


   Handling these requests on the server side is easy to implement using
   CGI or other, server-specific, extension mechanisms.  CGI scripts
   will see the incoming URI in the QUERY_STRING environment variable.
   Any %encoded characters in the URN will remain in their %encoded
   state in that string. The script can take the URN, look it up in a
   database, and return the requested information.

   One caveat should be kept in mind. The URN syntax document [4]
   discusses the notion of lexical equivalance and requires that
   resolvers return identical results for URNs that are lexically
   equivalent. Implementors of this specification must be careful to
   obey that rule. For example, the two requests below MUST return
   identical results, since the URNs are lexically equivalent.
       GET /uri-res/N2L?urn:cid: HTTP/1.0
       GET /uri-res/N2L?URN:CID: HTTP/1.0

3.0 Service-specific details:
=============================

   This section goes through the various resolution services established
   in the URN services document [5] and states how to encode each of
   them, how the results should be returned, and any special status
   codes that are likely to arise.

   Unless stated otherwise, the THTTP requests are formed according to
   the simple convention above, either for HTTP/1.0 or HTTP/1.1. The
   response is assumed to be an entity with normal headers and body
   unless stated otherwise. (N2L is the only request that need not
   return a body).

3.1  N2L (URN to URL):
----------------------

   The request is encoded as above. The URL MUST be returned in a
   Location:  header for the convienience of the user in the most common
   case of wanting the resource. If the lookup is successful, a 30X
   status line SHOULD be returned. HTTP/1.1 clients should be sent the
   303 status code. HTTP/1.0 clients should be sent the 302 (Moved
   temporarily) status code unless the resolver has particular reasons
   for using 301 (moved permanently) or 304 (not modified) codes.

   Note that access controls may be applied to this, or any other,
   resolution service request. Therefore the 401 (unauthorized) and 403
   (forbidden) status codes are legal responses. The server may wish to
   provide a body in the response to explain the reason for refusing
   access, and/or to provide alternate information about the resource,
   such as the price it will cost to obtain the resource's URL.




Daniel                        Experimental