Support options request

[Otto-AA]

While writing tests for solid-file-client I found out that solid-auth-cli doesn't yet supports the OPTION method. I think it should be implemented, as it is also part of the api-spec (you can take a look at it here), so if you have time for that it would be nice to have :)

[jeff-zucker]

This is actually all handled by solid-rest-file. I just added HEAD to it last week to support our solid-file-client tests. OPTIONS was on my lists, I'll add it today.

[jeff-zucker]

I would suggest that, for the time-being, you just use a web-based profile document to test options and head , that's what I do in my tests. Also, is there any chance you can make head be getHead - it is the only method I'd like to include in the higher-level methods that is not a verb.

[jeff-zucker]

Some questions about OPTIONS

I'm guessing that I should return Access-Control-Allow-Credentials: false. But otherwise return pretty much what the link you provided shows. Solid-Rest itself will return all options but that can be over-ridden by the storage handler, e.g. solid-rest-file won't accept PATCH at the moment.

I am not quite sure about User, Triples, Vary, I guess I'll look at what NSS does. But if you have any thoughts, let me know.

What about E-Tags? Should I do a random-number kind of thing? But how would I implement the actual functionality of it?

[Otto-AA]

I don't know much about these so I'd suggest to ask someone from NSS or search in the solid-spec repo (and create an issue there if you don't find anything).

What I know: Access-Control-Allow-Credentials: false is always the wrong way according to MDN. Either include the header and set it to true, or don't include it (which is what you'd expect with false).

I'll copy a portion of MDN for E-Tags:

Entity tags uniquely representing the requested resources. They are a string of ASCII characters placed between double quotes (Like "675af34563dc-tr34"). The method by which ETag values are generated is not specified. Oftentimes, a hash of the content, a hash of the last modification timestamp, or just a revision number is used. For example, MDN uses a hash of hexadecimal digits of the wiki content.

Hence I'd suggest to hash the content, e.g. you could use a etag package for that (or take a look at how they do it, it seems quite simple). Here is the relevant code used:

/**
 * Generate an entity tag.
 *
 * @param {Buffer|string} entity
 * @return {string}
 * @private
 */

function entitytag (entity) {
  if (entity.length === 0) {
    // fast-path empty
    return '"0-2jmj7l5rSw0yVb/vlWAYkK/YBwk"'
  }

  // compute hash of entity
  var hash = crypto
    .createHash('sha1')
    .update(entity, 'utf8')
    .digest('base64')
    .substring(0, 27)

  // compute length of entity
  var len = typeof entity === 'string'
    ? Buffer.byteLength(entity, 'utf8')
    : entity.length

  return '"' + len.toString(16) + '-' + hash + '"'
}

I don't know though if it should be computed every time it is requested, or just once and then stored in a meta file. Latter seems more efficient, but that's definitely not my expertise.

[jeff-zucker]

Moving this to solid-rest