Using Prefer headers with Content-Location

Hello HTTP working group,

I’m seeking expert opinion on whether it is permissible to define a Prefer
header  [rfc7240] which allows a client to request specific, optional
behavior from a server in relation to the presence of a URI in the
Content-Location header in PUT or POST requests.   If this is not the
correct venue, I apologize in advance.

To be concrete, RFC7231 states, in section 3.1.4.2:

 “A user agent that sends Content-Location in a request message is
   stating that its value refers to where the user agent originally
   obtained the content of the enclosed representation”

and

“An origin server that receives a Content-Location field in a request
   message MUST treat the information as transitory request context
   rather than as metadata to be saved verbatim as part of the
   representation.  An origin server MAY use that context to guide in
   processing the request or to save it for other uses, such as within
   source links or versioning metadata.  However, an origin server MUST
   NOT use such context information to alter the request semantics”

The Fedora (Flexible Extensible Digital Object Repository Architecture;
http://fedora.info) project is software used by libraries, museums, and
academic institutions for preserving, curating, and disseminating digital
assets.  For the last 20 years or so, it has had “external content” use
cases which involve interacting with content outside the repository in
specific ways.  As part of a process of updating its LDP-based API
specification, I am exploring whether we can leverage the Content-Location
header in conjunction with specific Prefer headers in requests to satisfy
 “external content” use cases such as:

- Create a resource that redirects to the URL given in Content-Location
- Create a resource that proxies content present at Content-Location
- Asynchronously copy/archive the content present at Content-Location

As an example, suppose we define (and perhaps attempt to register)
preference for use in Prefer headers called “content-resolution” with
values “redirect”, “copy”, and “proxy”.  For servers that understand and
implement those preferences, they are directives on how to interpret and
use the value at Content-Location.  So for a request like this:

POST /path/to/container
Slug: abc123
Content-Type: video/mpeg
Prefer: content-resolution=”redirect”
Content-Location: http://s3.amazonaws.com/obscure/bucket/location/abc123
[empty body]

.. a server that supports the preference might respond with:

201
Preference-Applied: content-resolution
Location: http://repository.example.org/path/to/container/abc123

A subsequent response to GET on /path/to/container/abc123 would then be a
redirect:

307
Location: http://s3.amazonaws.com/obscure/bucket/location/abc123


The general idea is that any special processing on Content-Location is
defined in another spec, in response to the presence of a Prefer header.
Servers that do not support such preference will ignore it (and
Content-Location will likely have no particular significance). RFC7231 says
“an origin server MUST NOT use such [Content-Location] context information
to alter the request semantics”.  So is it permissible to use a preference
in a Prefer header to request different request semantics, as illustrated
above?  If the above pattern does not violate RFC7231, then our community
might find it worthwhile to explore further as a mechanism to satisfy our
“external content” use cases.


Thank you very much,

  -Aaron

Aaron Birkland
Sr. Software Engineer
The Sheridan Libraries and Museums
Johns Hopkins University