You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
Activity
RubenVerborgh commentedon Nov 14, 2018
To be determined: does this depend on auth status?
dmitrizagidulin commentedon Nov 14, 2018
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 commentedon Nov 14, 2018
Specifically, the RFC states:
—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 commentedon Oct 12, 2024
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:
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
PATCHone of those:That doesn't seem right. Notice also that
COPYis not listed where it was listed in theOPTIONS. This can be a new issue.That seems fine mostly but again
COPYis missing where it was inOPTIONS. Then again, it is not strictly wrong in that the server could have changed its mind, e.g., no longer offeringCOPY. I think though the server could've omittedAllowin the response since it was successful any way.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.