Where are Slug headers handled?

[michielbdejong]

We want to support Slug headers, but ResourceStore#addResource doesn't seem to have a clear way of passing that value to it? Should it go into the metadata of the representation somewhere?

[RubenVerborgh]

Agreed, all metadata about the representation belongs in RepresentationMetadata.

As per @pmcb55's suggestion, RepresentationMetadata has an extension point through the fact that it is exposes an Array<Quad>. So by minting a (possibly internal) predicate for Slug, you can store such information.

Additionally, a specific direct getter for it could be added.

---

Instead of exposing raw, we could also consider RepresentationMetadata to implement https://rdf.js.org/dataset-spec/#datasetcore-interface. (It would be constant, so add and delete would throw.) Unfortunately, I noticed that the match method has strong implementation requirements (some of which I hope are a bug: rdfjs/dataset-spec#55).

A question is whether we want implementations of the RepresentationMetadata to be backed by an in-memory RDF store or not. My hunch is that this would be too expensive, since fields like contentType would have to be translated to triple and back multiple times then.

Maybe for now a String field for Slug might do. (Implementation note: whatever component parses Slug should also perform strong checks on the suggested value, such that it contains a valid URL and does not contain ../ sequences.)

[acoburn]

Implementation note: whatever component parses Slug should also perform strong checks on the suggested value, such that it contains a valid URL and does not contain ../ sequences.

This is really important, and one will want to always reference the applicable specification as regards parsing rules for the header. Even though all headers will be strings at the HTTP protocol level, they each may have specific rules regarding their semantic structure.

Slug headers, in particular, should be understood as percent-encoded strings, so be sure to URL-decode them first.

Packing all headers into an Array<Quad> is appealing, but unless you have the header value represented as a simple string literal, it may be challenging to represent highly structured headers as RDF (e.g. Prefer headers with various attribute permutations or Accept headers with complex q values and/or profile attributes). OTOH, if Array<Quad> is the defined extension point for arbitrary header values, then using that makes sense.

[RubenVerborgh]

This is really important, and one will want to always reference the applicable specification as regards parsing rules for the header.

Agreed. This is why the diagram also suggests small specific parsers rather than one omniscient parser, such that all these details can be tested at once.

@michielbdejong I anticipate the number of such small parsers to become large. Rather than passing them all directly to LdpHandler, we might want to introduce an intermediate object RequestParser whose sole job is to coordinate smaller parsers. Then LdpHandler just needs to call that object's parse method and dispatch the components of the returned value.

---

it may be challenging to represent highly structured headers as RDF (e.g. Prefer headers with various attribute permutations or Accept headers with complex q values and/or profile attributes)

Indeed, so small note: RepresentationMetadata is for metadata belonging to concrete representations, which would only have one content type and a well-defined list of profiles.

Content negotiation happens through a separate RepresentationPreferences object (which, so far, has not been detailed yet). I expect that object to require custom implementation due to its complexity, and I have currently not identified a need for extensibility through quads.

---

@michielbdejong For both cases, let me know if you would like additional diagrams.

[RubenVerborgh]

Resolving this for now; can be reopened if new concerns arrive.