Prefer-Push

prefer-push.md

Prefer-Push: item, icon

Client asks the server to push all resources that are linked via the item and icon relations of the context resource.

Prefer-Push: *

Client asks the server to push every link relation. I think this is a little controversial, but some people asked.

Prefer-Push: "https://example.org/rels/fun", describedby

Client asks to push the describedby and https://example.org/rels/fun link relation. (every custom link relation is a uri, so this syntax has to support both simple strings and uris.

Prefer-Push: item(author)`

Push the resource(s) behind the item relation. After pushing, follow the author link(s) from every item relation and push those as well. This is a level-2 push, and also controversial. Do we need this? Opinions are devided. I thought would be good to try and explore how multi-level pushes might look like, if we want them.

Prefer-Push: item("https://example.org/rels/account", icon), "collection"

Push:

1. The resource(s) behind the collection link(s0
2. The resource(s) behind the item, and from those:
   1. The resources behind the https://example.org/rels/account link
   2. The resources behind the icon link.

CSS selector syntax

@ashbjornu proposed using CSS selector syntax for these instead. The above 5 headers would in his proposal be serialized as:

Prefer-Push: item, icon
Prefer-Push: *
Prefer-Push: url("https://example.org/rels/fun"), describedby
Prefer-Push: item > author
Prefer-Push: item > url("https://example.org/rels/fun"), item > icon, collection

SPARQL property paths

I propose to employ subset of SPARQL's syntax, property paths. Well, the actual use would have to be a bit more relaxed, given that SPARQL requires each property in a path to be a variable (?rel), URI (<http://whatever>) or QName (schema:name).

Prefer-Push: item, icon
Prefer-Push: *
Prefer-Push: <https://example.org/rels/fun>, describedby
Prefer-Push: item/author
Prefer-Push: item / ( <https://example.org/rels/account> | icon), collection

Interestingly, although unsurprisingly, SPARQL doesn't support a wildcard because instead a variable would be used in query in place of the relation.
Note that whitespace around the operators is ignored.