CGI script arguments are dropped on Partial Redirects.

Arguments for CGI scripts sent as part of the PURL (GET request) or in the HTTP message body (POST request) are dropped for partial redirects requests.

For example, if we have the PURL /NET/SCRIPT which points to http://www.oclc.org/cgi-bin/script.cgi, and a request is sent to the PURL server for /NET/SCRIPT?arg=Hello, the redirect returned to the client will be http://www.oclc.org/cgi-bin/scripts.cgi not http://www.oclc.org/cgi-bin/scripts.cgi?args=Hello.

PURLs with local references (e.g. http://purl.oclc.org/OCLC/PURL/FAQ-nolocal#toc6.0) are not handled correctly by some clients.

NOTE: This problem does not occur when the resource referenced by a PURL is being "served locally" by the PURL resolver (e.g. http://purl.oclc.org/OCLC/PURL/FAQ#toc6.0). This is a configuration option of the PURL resolver that causes it to serve the actual resource (instead of a redirect) for a PURL whose associated URL references a resource stored under the resolver's file space. Even then, this problem still occurs for any PURL whose URL references a resource that the resolver doesn't serve locally.

A local reference (i.e. #toc6.0) is a directive to the HTTP client (browser). It is the client's responsibility to act on this directive in relation to the requested document once the document is received. Therefore, this behavior is dependent upon the client. Not all clients handle local references the same way.

Some clients (correctly) do not send the local reference part of the PURL to the PURL resolver but then (incorrectly) drop the local reference upon receiving the redirect from the PURL resolver and therefore fail to act on the local reference directive when the actual document is received.

As a result, PURLs with local references, such as the one in the example above, resolve to (the beginning of) the document referenced by the PURL under some Web browsers. To determine how your browser behaves, try the example PURL above. If it takes you to the top of the PURL FAQ, then your browser is not handling local references correctly. If it takes you to section 6.0 of the PURL FAQ, then your browser is handling local references correctly. Either way, you should still end up with the PURL FAQ.

There is nothing in the OCLC PURL Resolver Software that prevents you from creating a PURL which contains a "#" character. However, correct HTTP clients will truncate such PURLs at that character, making the PURL unresolvable or making it resolve to some other resource if the truncated PURL exists. Either way, such PURLs will never resolve as intended. Therefore, we recommend that you do not create PURLs containing the "#" character.

Perl5 may not be locking files correctly

We have discovered, particularly on Solaris 2.X systems, that Perl5 can appear to be built correctly but still fail to lock files correctly using flock. This can cause corruption in a PURL resolver's database. The configure script (run during installation - see the INSTALL document in the distribution) determines whether or not your Perl5 installation locks files correctly. If your Perl5 installation does not lock files correctly using flock, do not run the PURL resolver until you have corrected the problem with Perl.

We were able to make our Perl5 installation on Solaris 2.5 use flock properly by performing the final link of the perl executable using the BSD compatibility library by using /usr/ucb/cc as the linker. This will not work if you have not purchased Sun's BSD compatibility package.