Resource reports created when overwriting container

As I was developing a test for containment triple protection, I came across NSS behaviour that seems to be that I can create a text/plain representation of an existing container. This doesn't seem right, and has potentially security implications, depending on what is actually happening here behind the scenes. This illustrates what I'm seeing:

The first request simply confirms that the container exists:

2022-01-19 00:45:25,435 DEBUG [com.int.karate] (main) request:
1 > GET https://solid-test-suite-alice.inrupt.net/shared-test/P03W0Q/A0R3nz/
1 > Authorization: DPoP ***2cmMdQ
1 > User-Agent: Solid-Conformance-Test-Suite
1 > DPoP: ***b72d5Q
1 > Host: solid-test-suite-alice.inrupt.net
1 > Connection: Keep-Alive
1 > Accept-Encoding: gzip,deflate


2022-01-19 00:45:25,898 DEBUG [com.int.karate] (main) response time in milliseconds: 446
1 < 200
1 < X-Powered-By: solid-server/5.6.16
1 < Vary: Accept, Authorization, Origin
1 < Access-Control-Allow-Credentials: true
1 < Access-Control-Expose-Headers: Authorization, User, Location, Link, Vary, Last-Modified, ETag, Accept-Patch, Accept-Post, Updates-Via, Allow, WAC-Allow, Content-Length, WWW-Authenticate, MS-Author-Via, X-Powered-By
1 < Allow: OPTIONS, HEAD, GET, PATCH, POST, PUT, DELETE
1 < Link: <.acl>; rel="acl", <.meta>; rel="describedBy", <http://www.w3.org/ns/ldp#Container>; rel="type", <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"
1 < WAC-Allow: user="read write append control",public=""
1 < MS-Author-Via: SPARQL
1 < Updates-Via: wss://solid-test-suite-alice.inrupt.net
1 < Content-Type: text/turtle
1 < Date: Wed, 19 Jan 2022 00:45:25 GMT
1 < Connection: keep-alive
1 < Transfer-Encoding: chunked
1 < Set-Cookie: nssidp.sid=s%3ATSOm8DBLX7QriEAoQmzYa8cMVOxrBAb_.4hS1plHGLgkleF%2FdQTMeWnaVxn2reGP2c%2FW37yDF1%2FU; Max-Age=1642639525000; Expires=Sat, 23 Mar 54075 13:42:05 GMT; Domain=inrupt.net; Secure
@prefix : <#>.
@prefix dct: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix stat: <http://www.w3.org/ns/posix/stat#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@prefix A0R: <>.
@prefix Vxm: <Vxm4lW/>.
@prefix pl: <http://www.w3.org/ns/iana/media-types/text/plain#>.
@prefix tur: <http://www.w3.org/ns/iana/media-types/text/turtle#>.

A0R:
    a ldp:BasicContainer, ldp:Container;
    dct:modified "2022-01-19T00:45:25Z"^^xsd:dateTime;
    ldp:contains <jl1ElE.txt>, <pl6EnX.txt>, Vxm:, <zx8y0g.ttl>;
    stat:mtime 1642553125.196;
    stat:size 4096.
<jl1ElE.txt>
    a pl:Resource, ldp:Resource;
    dct:modified "2022-01-19T00:45:24Z"^^xsd:dateTime;
    stat:mtime 1642553124.98;
    stat:size 6.
<pl6EnX.txt>
    a pl:Resource, ldp:Resource;
    dct:modified "2022-01-19T00:45:24Z"^^xsd:dateTime;
    stat:mtime 1642553124.756;
    stat:size 5.
Vxm:
    a ldp:BasicContainer, ldp:Container, ldp:Resource;
    dct:modified "2022-01-19T00:45:25Z"^^xsd:dateTime;
    stat:mtime 1642553125.196;
    stat:size 4096.
<zx8y0g.ttl>
    a tur:Resource, ldp:Resource;
    dct:modified "2022-01-19T00:45:24Z"^^xsd:dateTime;
    stat:mtime 1642553124.496;
    stat:size 60.

Then, the second request puts a text/plain resource camouflaged as Turtle to the same container:

2022-01-19 00:45:25,931 DEBUG [com.int.karate] (main) request:
2 > PUT https://solid-test-suite-alice.inrupt.net/shared-test/P03W0Q/A0R3nz/
2 > Authorization: DPoP ***2cmMdQ
2 > User-Agent: Solid-Conformance-Test-Suite
2 > DPoP: ***oZ5u0g
2 > Cookie: nssidp.sid=s%3ATSOm8DBLX7QriEAoQmzYa8cMVOxrBAb_.4hS1plHGLgkleF%2FdQTMeWnaVxn2reGP2c%2FW37yDF1%2FU
2 > Content-Type: text/plain; charset=UTF-8
2 > Content-Length: 49
2 > Host: solid-test-suite-alice.inrupt.net
2 > Connection: Keep-Alive
2 > Accept-Encoding: gzip,deflate
<> <http://www.w3.org/ns/ldp#contains> </foobar>.

2022-01-19 00:45:26,348 DEBUG [com.int.karate] (main) response time in milliseconds: 416
2 < 201
2 < X-Powered-By: solid-server/5.6.16
2 < Vary: Accept, Authorization, Origin
2 < Access-Control-Allow-Credentials: true
2 < Access-Control-Expose-Headers: Authorization, User, Location, Link, Vary, Last-Modified, ETag, Accept-Patch, Accept-Post, Updates-Via, Allow, WAC-Allow, Content-Length, WWW-Authenticate, MS-Author-Via, X-Powered-By
2 < Allow: OPTIONS, HEAD, GET, PATCH, POST, PUT, DELETE
2 < MS-Author-Via: SPARQL
2 < Content-Type: text/plain; charset=utf-8
2 < Content-Length: 7
2 < ETag: W/"7-rM9AyJuqT6iOan/xHh+AW+7K/T8"
2 < Date: Wed, 19 Jan 2022 00:45:26 GMT
2 < Connection: keep-alive
2 < Set-Cookie: nssidp.sid=s%3ATSOm8DBLX7QriEAoQmzYa8cMVOxrBAb_.4hS1plHGLgkleF%2FdQTMeWnaVxn2reGP2c%2FW37yDF1%2FU; Max-Age=1642639526000; Expires=Sat, 23 Mar 54075 13:58:46 GMT; Domain=inrupt.net; Secure
Created

NSS responds 201 Created to that, and that's not what I expected. Now, you could argue it is just a plain text representation of the container, but we have inherited LDPs definition of a container, which is an RDF Source, so I believe this is incorrect.

I haven't investigated what happens further, I hope it doesn't overwrite the container representation, but I hope you can investigate this.

As I was doing something else, I'm not going to keep this test for now, it was a small mistake that I stumbled to test this.

Reproduce the reported PUT of text/plain content to an existing container, then trace the server's request handling for container URLs and resource creation. Done means the behavior is covered by a regression test and the response matches the expected LDP container semantics without overwriting the container representation.