Remove server-options-asterisk-accept-headers. Add OPTIONS to server-accept-headers

[csarven]

Related issue: #356

Not all servers will be configured to receive/respond to OPTIONS * (asterisk-form). Clients can't rely on all servers (be instructed by their respective URI owners) allowing the request.

Checking for Accept-* header options should be possible with OPTIONS targeting a resource (origin-form or absolute-form).

[kjetilk]

I think OPTIONS * is the most promising candidate for a sane, general discovery mechanism for HATEOAS, but given that nginx doesn't support it, it is indeed not possible to rely on 😭

[TallTed]

sighs Might be worth logging an issue on nginx, as OPTIONS * is becoming ever more important, as web servers continue to deliver more than basic web services, but not always the same set of extensions, features, etc.

[acoburn]

This was raised with nginx and subsequently closed as "won't fix".

[TallTed]

Thanks for finding that, @acoburn. I don't see a way to comment on a closed issue there; might be because I haven't logged in to their trac system, or because I'm not a contributor to their project. I think that providing them with some new (to them, anyway) information -- i.e., that while nginx doesn't expect OPTIONS * and so won't handle it directly, many are deploying nginx as a proxy to load balance and otherwise protect actual back-ends, which may expect OPTIONS * as they support more (and more complex) services, and users (or their apps/agents) may have reason to ask what the back-end server supports, distinctly from what it supports for any specific resource -- and relaying such HTTP/S API calls to the back-end server in such proxy configurations would be worthwhile.

[acoburn]

@TallTed even if nginx were to support such an operation, it is currently not possible to issue such a request via the JavaScript fetch function in any browser. As such, the feature would still not be usable for most of Solid. Either way, removing this requirement from the Solid protocol is a good direction.

[csarven]

Server and client implementations in the wild is an important signal but it is perhaps worth repeating that the primary reason for this PR is about removing the assumption that the owner of a URI delegates authority to a server to receive/respond to request targets in asterisk-form.

Even if software (the servers, proxies, clients, SDKs, applications, .. at any level..) have the capability to request and respond to OPTIONS * (eg from RFC 7230):

OPTIONS * HTTP/1.1
Host: www.example.org:8001

a Solid server instance may never have been configured to even receive such request. Which is why "[c]lients can't rely on all servers (be instructed by their respective URI owners) allowing the request."

As it stands, the Protocol requires that servers must make a storage (root container), at any URI path ending with a slash, but nothing further.

The same reasoning was applied to removing any expectation that a Solid server can receive/respond to requests at root path / ( #357 ) or any specific URI for that matter (e.g., /.well-known/solid, /profile/card, ...)

---

The Protocol can be changed to require specific request targets but until there is a need to force all server instances to receive/respond to specific requests, we should continue to tighten the spec.

[csarven]

Double-checked: neither fetch and xhr specs describe how OPTIONS * can be requested. Also did quick tests from dev console in Firefox Nightly and Chromium. No go. Asked in whatwg in case I missed a spec: https://matrixlogs.bakkot.com/WHATWG/2022-01-03#L11-L12 (FWIW):

11:26 | <csarven> | Is it possible to request target in asterisk-form (OPTIONS *) with fetch, xhr (or another)? Any pointers on history/discussion would be great.
12:35 | <annevk> | csarven: it's not possible, don't recall discussion

---

OPTIONS * is neat but doesn't appear to be usable for the Solid ecosystem at this time.