Servers responding to request targets using the asterisk-form or the origin-form

[csarven]

While the Solid Protocol requires servers to conform to RFC 7230 and RFC 7231, there may exist Solid server instances that cannot receive requests using the asterisk-form or a particular absolute-path (and path segments in lower hierarchy) as target.

It is important to consider whether any of the following requirements should be included in the Solid Protocol:

• Servers MUST respond to request targets using the asterisk-form (RFC 7230).

• Servers MUST respond to request targets using the origin-form (RFC 7230).

The first requirement is relevant for communication options: OPTIONS *. If servers cannot respond to requests using the asterisk-form as target, the following requirement either needs to be removed:

Servers MAY include the HTTP Accept-Patch, Accept-Post and Accept-Put headers in the response of a OPTIONS * request.

or the requirement for those Accept- headers should be in the response of OPTIONS for authorized requests.

The second requirement is relevant when responding to specific resources, and perhaps most importantly whether server can respond to request target: /.

[acoburn]

It may be worth noting that any Solid server running behind an nginx proxy will have difficulty responding to OPTIONS * requests.

https://trac.nginx.org/nginx/ticket/1882

In my experience it simply doesn't work. It would be unfortunate if a specification requirement made it impossible to use one of the most widely deployed reverse proxy servers on the web, especially one that is built into most kubernetes deployments.

I have no concerns about including those Allow-* headers in authenticated OPTIONS /resource-path responses. I also have no concerns about OPTIONS / requests.

[kjetilk]

It may be worth noting that any Solid server running behind an nginx proxy will have difficulty responding to OPTIONS * requests

Oh no! Indeed, nginx is an extremely important piece of software, so if they decided this, we can't use that. :-(

[acoburn]

Related to the origin-form request (e.g., GET / HTTP/1.1), the "get-off-my-lawn" RFC 8820, section 2.3 is relevant.

The key point made there is that a specification should not require or expect a certain path for applications.

To avoid collisions, rigidity, and erroneous client assumptions,
Specifications MUST NOT define a fixed prefix for their URI paths --
for example, "/myapp" -- unless allowed by the scheme definition.

Thus, requiring servers to respond in a certain way to requests at the root path /, would go against the recommendation of this RFC.

[csarven]

The delegation precondition is analogous to https://solidproject.org/TR/protocol#storage-owner-uri-ownership :

[Solid Protocol] does not describe the relationship between a Solid storage "owner" and Web architecture’s URI ownership.

Solid Protocol should not describe a requirement that presumes that the owner of a URI delegates authority to a server or an application.

Conformance to origin-form, absolute-form is not coupled with the notion of owners delegating URI with path / to a server. URI with path / is allowed by the http URI scheme definition (RFC 7230, RFC 3986) - it is not a new reservation or an extension of the URI structure. If the Solid Protocol were to require that the owner of URI with path / needs to delegate authority to the server, it would not conflict with RFC 8820.

---

The following statement should be removed from the specification because the URI owner may not have delegated authority to the server:

Clients may check the root path of a URI for the storage claim at any time.

Created #357

[timbl]

If currently the existing Solid servers do not support this feature, it seems that the Solid spec should continue not to include it. I gather the RFCs do not require server to response to OPTIONS * . Nothing is broken. the discussion seems like a distraction. Do we need to explicitly say in the spec that this feature is not available? What is the problem?

[csarven]

This issue is intended to remove assumptions about the availability of a Solid server responding to certain requests. Comments in the issue #355 for example considers the possibilities like OPTIONS * , URI path with / , or even .well-known/solid .. and there are many other issues (some linked from 355) that essentially touch on the same assumption. Understanding/agreeing on not making that assumption removes all those possibilities, and discussions in one go. I want this on record... irrespective to whether existing (or WIP) servers are capable of answering calls to OPTIONS * or ..

[csarven]

Re #server-options-asterisk-accept-headers :

Servers MAY include the HTTP Accept-Patch, Accept-Post and Accept-Put headers in the response of a OPTIONS * request.

As noted, not all servers would be configured to receive/respond to OPTIONS *. There is no other requirement that depends on this requirement. This statement can be safely removed or left as is. Alternatively, and this may actually be better: OPTIONS can be listed alongside the requirement for GET and HEAD response with the Accept-* headers ( #server-accept-headers ):

Servers MUST indicate supported media types in the HTTP Accept-Patch [RFC5789], Accept-Post [LDP] and Accept-Put [The Accept-Put Response Header] response headers that correspond to acceptable HTTP methods listed in Allow header value in response to HTTP GET and HEAD requests.

Any reason why we shouldn't?

[acoburn]

First, 👍 on removing OPTIONS *

Second, it is possible to put OPTIONS requests into two categories:

1. CORS pre-flight requests. These never include authorization headers
2. Everything else

Because Accept-* headers may disclose information about the nature and/or existence of a resource, it would be important to be clear that Accept-* response headers will be present only for authorized requests, and therefore not for CORS preflight requests.

[csarven]

There is "When responding to authorized requests:" before the requirement on OPTIONS * and that was intended to exclude the CORS pre-flight case. Is that alright? Can we then put OPTIONS alongside GET and HEAD ( #server-accept-headers ). Noting the proposal in PR https://github.com/solid/specification/pull/353/files#diff-dcde422fcd5ad628eda53177df32d7ed1c10ac7ec86e62606b1d8979c812bdfcR686 that brings the condition to the requirement - I'm fine with that particular line but haven't processed that PR in full (re Allow discussion).

[michielbdejong]

@csarven this issue hasn't been updated in a long time and it looks like it was resolved by #369 at the time, right?
Can it be closed?

[csarven]

For anyone reading this in the future:

PR 369 removed the mention of asterisk-form since it can't be reliably implemented.

That aside, PRs 369 and 378 did clarify that it'd be possible to get a hold of Accept- headers in the case of authorized requests with OPTIONS.

PR 357 also removed the expectation of origin-form with / being available by servers. There is no other origin-form required by the Solid Protocol.

What all of this generally entails is that - perhaps with some context of Issue 355 - the URI owner needs to allocate a resource that describes storage description, and that needs to be discoverable. These are essentially covered by the Storage Resource section in https://solidproject.org/ED/protocol#storage-resource

Closing this issue, as the considerations raised have been adequately addressed at this time.