search

trellis-ldp / trellis

Trellis is a platform for building scalable Linked Data applications
https://www.trellisldp.org
Apache License 2.0
105 stars 21 forks source link

Decide on configuration defaults #393

Closed acoburn closed 5 years ago

acoburn commented 5 years ago

There are quite a few configuration properties that control small, but potentially important, details of the Trellis runtime. The process by which the default values have been chosen is based more on setting the default = the earlier (non-configurable) behavior, but that should be reviewed.

In particular, these values should be considered:

  1. ETags. Right now, an RDFSource will respond with a weak ETag, which is technically correct from the perspective of HTTP, but it's terribly inconvenient for clients that use those ETags for If-Match conditional operations. One can set the trellis.http.weak.etag property to false (default = true) to always respond with strong ETags (binary resources respond with strong ETags either way). I lean toward changing this to false as a default.

  2. Precondition required on PUT. The LDP specification encourages (SHOULD) a server to accept PUT requests only if they are done with precondition headers (If-Match, If-Unmodified-Since). By default, this is not enabled, though it needs to be turned on for the LDP test suite. I lean toward leaving this turned off, i.e. default = false.

  3. PUT uncontained. A PUT request to create a new resource performs a put-uncontained operation. That is, a parent container will not have an ldp:contains link to the child resource. This behavior can be changed with the trellis.http.put.uncontained configuration. The default value is true. I lean towards changing this to false as a default.

  4. Memento header dates. Memento link headers contain a date parameter with an RFC 1123 date string. These date strings contain a comma, which is perfectly legit, but a lot of link header parsers get tripped up with this. The trellis.http.memento.headerdates configuration key can be used to omit these header parameters. The default is to include those dates, i.e. default = true. I have very little opinion about this one.

There are other component-specific configuration defaults, but those are of less importance than the defaults defined in the HTTP layer itself.

ajs6f commented 5 years ago
  1. I'm not clear about this: how do we send strong ETags for RDF Sources?
  2. 👍
  3. 👍 (as long as we keep the option for those of us who need it)
  4. Are these headers required by Memento? Not sure how we can drop them, if so?
acoburn commented 5 years ago

  1. The EntityTag class has a boolean parameter, defining whether the ETag is weak or strong. For example, the code creating the object is here. Rather than defining the ETag (for RDFSources) to always be weak, this is controlled by a configuration parameter. FWIW, the Solid server responds with strong ETags for RDFSource resources.

  2. The date parameter is optional according to the Memento specification. We're not doing anything wrong by omitting them, but it is kind of convenient (in some contexts) to have that param present -- though in other contexts (i.e. naive Link parsers) those values can be very inconvenient.

ajs6f commented 5 years ago
  1. Ok, so for us, NonRDFSources could feature strong tags, but RDFSources wouldn't? (I think Solid is just wrong here.)
  2. Ok, then I have no opinion either. I don't know enough about what convenience they offer.
acoburn commented 5 years ago
  1. Technically, weak strong ETags on an RDFSource is going to be wrong if you can't guarantee byte-for-byte consistency, and I agree with that. It's also the case that this restriction is terribly inconvenient. So it's basically a question of pragmatism vs. technical correctness
ajs6f commented 5 years ago
  1. Sorry, you mean strong ETags are going to be wrong?
acoburn commented 5 years ago
  1. right, I just updated the comment. "Strong ETags are going to be wrong"
ajs6f commented 5 years ago

Ok, cool. I'm much more worried about the wrong than about the not-as-convenient, because sooner or later the assumption that RDFSources can guarantee octet-for-octet identity is going to bite anyone who makes it. I'm not going to lay down across the road on this, but I would much rather us default to correct and let people who want to play with fire take responsibility for burning themselves.

acoburn commented 5 years ago

That's completely fine with me. Default = correct, but you want to play with fire, you can do that.