...
| Excerpt |
|---|
When referencing content hosted outside of the repository, you can create an empty binary to act as a placeholder for the external content, specifying the URL of the external content. |
Instead of supplying the binary in the body of the request, you provide a Link header which uses the rel="http://fedora.info/definitions/fcrepo#ExternalContent" and specifies where to get the resource and how to handle it.
| Code Block |
|---|
Link: <http://example.org/some/content>; rel= |
| Code Block |
Content-Type: message/external-body; access-type=URL; URL="http://examplefedora.cominfo/external/content/file" |
See Example 4 from the Container REST API PUT method documentation for more information about creating a binary that redirects to external content.
When you retrieve the binary from Fedora, it sends a redirect to that URL. This allows you to attach relevant metadata to the binary, have it contained in a repository Container, etc., but still have the content served by a separate system.
...
definitions/fcrepo#ExternalContent"; handling="proxy"; type="image/tiff" |
The Fedora API specifies 3 methods of handling external content
- copy - Copy the binary from the provided URI and then treat it as a normal internal LDP-NR.
- redirect - On requests for the LDP-NR provide a redirect (302 Found or 307 Temporary Redirect) to the external URI.
- proxy - On requests for the LDP-NR proxy the request through the Fedora server the client with the same interaction as an internally stored LDP-NR.
The External Content Link also allows for a type= option. This is the content type that MUST be used by the server if provided.
If type= is omitted, then the server attempts to determine the Content-Type.
If the external URI has a file prefix (ie. local disk storage) then application/octet-stream is returned.
If the external URI has a http prefix then a HEAD request is made to the remote server to retrieve the Content-type header, if this header is not returned the resource cannot be added to the repository.