nodeSolidServer
POST/PUT in NSS allow multiple resource with same url and different content-type
You can create resources :
- https://pod/foo.txt with content-type
text/plain=> creates file :/foo.txt - https://pod/foo.txt with content-type
text/turtle=> creates file/foo.txt$.ttl - https://pod/foo.txt/ as a container => creates folder
/foo.txt
The first 2 have the same url and there are 2 different files created. All 3 have the same visual representation in SolidOs.
The first 2 should not occur and I think this is a bug For the third one I remember @timbl writing it should not occur, but did not find where. There was also a redirect discussion between foo/bar/ and foo/bar. His this something to do in GET ?
Is there any solid/specification, I did not find anything ? @csarven @michielbdejong
No issues with either one of those. They will create/replace resource given representation depending on request semantics. If /foo.txt exists, /foo.txt/ should not, and vice-versa. Redirect is optional.
@csarven thanks I shall work on correcting to only have one representation for 1. 2. 3. and let open redirect for more information
Hmm, not exactly sure what you are after.. but there is no limit on how many or what representations can potentially be made available for a resource. Just one per request. If you are considering whether to store one or more representations and have one of them available at request, that's entirely your (NSS's) call. You'll have to take care when updating of course.
Is this correct?
/foo.txt exists
PUT /foo.txt with any content type, overwrites
PUT /foo.txt/ fails
POST /foo.txt creates a new file with a different location
POST /foo.txt/ fails ??? or creates new folder with different location
/foo.txt/ exists
PUT /foo.txt fails
PUT /foo.txt/ fails
POST /foo.txt creates a new file with a different location
POST /foo.txt/ creates new folder with different location
The first 2 should not occur and I think this is a bug
I don't think it is a bug as long as the correct representation is returned given the respective Accept header on GET
@angelo-v
I do think it is a bug because it is not a question of data representation but of 2 different sets of data.
For example it can be an image and a text, or an RDF or any non RDF data
If it where different representations of the data, do you know how to replace the data ? Would you need to make a PUT to all the existing stored representations ?
I was with the idea that a representation should be stored in the format of the creation content-type
- If you ask with GET for a URL as ld-json that was created as turtle with a text/turtle content-type
- then make a PATCH, the result should be stored as turtle with text/turtle content-type
nota : my comments are not using the specification language, i'm just on the practical side
@csarven
/foo.txt exists, /foo.txt/ should not, and vice-versa
is this a 409 or a 403 ? I was thinking of 409 conflict - forbidden by the context not as such.
/foo.txt exists POST /foo.txt creates a new file with a different location
POST is an append operation, so server should append to the existing resource. POST to a (non-container) resource with an existing representation is currently unspecified in the specification. This is intentional. Whether that's possible for any media-type or how that's done is unspecified. However, we have discussed RDF merge as a good candidate, and that's likely to come into the specification. I'll have to review the issues before adding it in. RDF merge will happen when request Content-Type uses the media-type of an RDF document eg. text/turtle, application/ld+json, application/trig, text/html, application/xhtml+xml, image/svg+xml etc. The server is not required to support any or all of that. If it does merge, the encoded RDF graph should be the result of the merge of RDF triples.
/foo.txt exists POST /foo.txt/ fails ??? or creates new folder with different location
Fail (most likely) or redirect to /foo.txt. This is mentioned in the specification without ties to HTTP methods:
If two URIs differ only in the trailing slash, and the server has associated a resource with one of them, then the other URI MUST NOT correspond to another resource. Instead, the server MAY respond to requests for the latter URI with a 301 redirect to the former.
I'll try to further clarify requests like "/foo.txt exists [..] POST /foo.txt/". I suggest responding with the 404 status code. You could later consider including a response body with the problem details ( see https://github.com/solid/specification/issues/28 ) and/or use the ldp:constrainedBy for the link relation type ( see https://github.com/solid/specification/pull/185 ).
/foo.txt/ exists PUT /foo.txt/ fails
No. It should respond with 200 or 204 (while adhering to other requirements eg. not changing the containment triples), or possibly 202.
/foo.txt/ exists POST /foo.txt creates a new file with a different location
No. 404. The request target is /foo.txt and it doesn't exist. Nothing to append to. It doesn't matter if /foo.txt/ exists.
When authorization is taken into account, 403 should precede 404 where applicable. See https://github.com/solid/specification/issues/14#issuecomment-683480525 for more details. I plan to integrate the information from that comment into the specification, if not already covered.
/foo.txt/ exists POST /foo.txt/ creates new folder with different location
Only if the request included the Link header with LDPC, create /foo.txt/{id}/ , otherwise create (non-container) resource /foo.txt/{id} as per:
Servers MUST allow creating new resources with a POST request to URI path ending /. Servers MUST create a resource with URI path ending /{id} in container /. Servers MUST create a container with URI path ending /{id}/ in container / for requests including the HTTP Link header with rel="type" targeting a valid LDP container type.
Servers are not required to "store" different representations or have URLs for them different than the resource URL. Server just needs to respond with a representation when a resource is requested. Server can choose to expose representation URLs for read operations, however, for write operations, client needs to go through the resource URL.
See https://solid.github.io/specification/#resource-representations