Return correct Allow header on OPTIONS

[RubenVerborgh]

[RubenVerborgh]

To be determined: does this depend on auth status?

[dmitrizagidulin]

As mentioned in #931, the Allow: header is not authentication dependent. Its semantics are “this is what the server is capable of in general.”

On the other hand, the WAC-Allow: header (returned on HEAD requests) /is/ authentication dependent, and checks the resource acls etc.

[RubenVerborgh]

Specifically, the RFC states:

The "Allow" header field lists the set of methods advertised as
supported by the target resource. The purpose of this field is
strictly to inform the recipient of valid request methods associated
with the resource.

—https://tools.ietf.org/html/rfc7231#section-7.4.1

So no mention of auth there indeed, just the resource itself. Hence, it should always be GET/HEAD/OPTIONS/POST/PUT/PATCH/DELETE for Solid.

[csarven]

This issue is somewhat underspecified. (If it was an offshoot of another issue, there is no provenance). In any case, doing a quick check here:

curl -X OPTIONS -ik https://csarven.localhost:8443/
curl -X OPTIONS -ik https://csarven.localhost:8443/.well-known/solid
curl -X OPTIONS -ik https://csarven.localhost:8443/.acl

Allow: GET,HEAD

curl -X OPTIONS -ik https://csarven.localhost:8443/profile/card
curl -X OPTIONS -ik https://csarven.localhost:8443/public/

Allow: COPY,GET,HEAD,POST,PATCH,PUT,DELETE

Seems ok to me. Or put differently, the above FWIW is not incorrect as far as Solid Protocol or HTTP is concerned. The server is generally entitled to allow whatever it wants to.

Digging a bit closer, let's try to see if we can actually PATCH one of those:

$ curl -ik -X PATCH -H'Content-Type: application/sparql-update' https://csarven.localhost:8443/public/ -d 'INSERT DATA { <> <http://schema.org/name> "foo" . }'

HTTP/1.1 500 Internal Server Error

Allow: OPTIONS, HEAD, GET, PATCH, POST, PUT, DELETE

Original file read error: Error: EISDIR: illegal operation on a directory, read

That doesn't seem right. Notice also that COPY is not listed where it was listed in the OPTIONS. This can be a new issue.

$ curl -ik -X PATCH -H'Content-Type: application/sparql-update' https://csarven.localhost:8443/profile/card -d 'INSERT DATA { <> <http://schema.org/name> "foo" . }'

HTTP/1.1 200 OK

Allow: OPTIONS, HEAD, GET, PATCH, POST, PUT, DELETE

That seems fine mostly but again COPY is missing where it was in OPTIONS. Then again, it is not strictly wrong in that the server could have changed its mind, e.g., no longer offering COPY. I think though the server could've omitted Allow in the response since it was successful any way.

$ curl -ik -X PATCH -H'Content-Type: application/sparql-update' https://csarven.localhost:8443/.well-known/solid -d 'INSERT DATA { <> <http://schema.org/name> "foo" . }'

HTTP/1.1 401 Unauthenticated

Allow: OPTIONS, HEAD, GET, PATCH, POST, PUT, DELETE

Ok I guess.

So, again, this issue is underspecified because it doesn't refer to what would be acceptable for "correct". The current, cursory, responses are generally "correct" but may not be desirable or ideal which is a separate matter.

That aside, checking against tests is probably best at this point as to what's acceptable.