properly implement OPTIONS * HTTP/1.1

[TallTed]

Issue logged as requested by @dmitrizagidulin in comment on solid-spec PR 103.

OPTIONS * HTTP/1.1 should receive a response indicating the full capabilities of the server, as discussed in HTTP RFC 7231 section 4.3.7 "Request Methods -- Method Definitions -- OPTIONS" and 7230 section 5.3.4 "Message Routing -- Request Target -- asterisk-form".

The special * request-target does not designate any specific resource(s), and (some) capabilities presented for this request might not be available for any specific resources (in other words, might be available for no specific resources) handled by that server; this response only represents what the server is capable of -- what might be available for any resource thereon.

[TallTed]

I wonder whether CLOSING things tagged REVISIT makes sense, or would they be better kept in the OPEN list, and filtered out as/when appropriate? I ask because CLOSED things are rarely if ever REVISITED in practice. (And today, when I saw this as CLOSED in solid/solid-spec#103, I thought it had been done, not tabled. I think that will be the common interpretation.)

[RubenVerborgh]

The number of open issues was too large to be manageable; it was in the way of progress. I agree that this is not the best solution, but we haven't found anything else that is workable. Attention to vnext of the server will increase; only the very nasty blockers in this one will currently be considered (unless anyone has the bandwidth to take them up, in which case, open the issue and go).

[Ryuno-Ki]

@RubenVerborgh Maybe an approach similiar to what @zachleat is doing could help you: 11ty/eleventy#321 (comment) ?