3.1.1 LDP Containers  MUST be able to create LDP Containers: Tested in 3.3 MUST distinguish between triple types OR MUST return 409 with constrainedBy Link in headers for ldp:contains membership predicate if server cannot distinguish between triple types- We return a 409 because we can't distinguish and therefore the next 2 tests are not applicable.
 MAY permit ldp:contains membership predicate if server can distinguish between triple types- SHOULD allow Prefer header in request to distinguish triple types if server can distinguish triple types
3.1.2 LDP-NR creation - SHOULD create an LDP-NR if creation request includes NonRDFSource type Link in headers, regardless of Content-Type headers
3.1.3 Constraints Document 3.1.4 Data Model 3.2 HTTP GET3.2.1 Additional values for the Prefer header - SHOULD support PreferInboundReferences URI in Prefer header
- MAY support PreferContainedDescriptions URI in Prefer header
3.2.2 LDP-RSs - MUST return Preference-Applied header if request's Prefer header is honored (Always applied)
 note: also test with a combinations of Prefer headers: some valid, some invalid
- MUST return describes Link to LDP-NR if request is to associated LDP-RS
3.2.3 LDP-NRs - MUST return Digest header as directed by request's Want-Digest header
3.3 HTTP HEAD- MUST NOT return a body
- SHOULD return same headers as if the request was a GET
- Almost perfect: Binary resources have duplicate headers that are not seen on HEAD
| Jira |
|---|
| server | DuraSpace JIRA |
|---|
| serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
|---|
| key | FCREPO-2714 |
|---|
|
- MUST return a Digest header if the same request as a GET would have
 MAY omit payload headers from response
3.5 HTTP POST- MUST be supported on LDPC
- MAY not be supported on LDPCv
- MUST include default interaction model in constrainedBy Link header
- Correct for both LDP-RS and LDP-NR
3.5.1 LDP-NRs - MUST support creation of LDP-NRs
- MUST create and associate an LDP-RS when an LDP-NR is created
- MUST return 409 if request Digest header does not match calculated value for content of new LDP-NR
- SHOULD return 400 if request Digest header's type is not supported (Should 'type' be 'algorithm', like the RFC?)
3.6 HTTP PUT- MAY include type Link header in request
- SHOULD return 409 if request's type Link is not resource's current type or subtype thereof, or not in LDP namespace
- MUST change resource's type if request's type Link is a subtype of resource's current type
- MUST change resource's interaction model if request's type Link has an LDP interaction model
3.6.1 LDP-RSs  MUST support PUT on LDP-RSs for non-server-managed triples- MUST return 4xx (409) if request modifies server-managed triples on a LDP-RS
- MUST return constrainedBy Link in headers if request modifies server-managed triples on a LDP-RS
- MUST return info in body about which statements could not be persisted if request modifies server-managed triples on a LDP-RS
 Currently we allow the use of the -Dfcrepo.properties.management=relaxed option to allow updating server managed triples.
3.6.2 LDP-NRs (Danny Bernstein) - MUST support PUT on LDP-NRs to replace binary content
- MUST return 409 if request Digest header does not match calculated value for new content of target LDP-NR
- SHOULD return 400 if request Digest header's type is not supported
3.6.3 Creating resources with HTTP PUT - If PUT is supported for creation of LDP-NRs, MUST create and associate an LDP-RS when an LDP-NR is created
- MUST be supported on LDP-RSs
- MUST support Content-Type: application/sparql-update
- MAY support other update types
- MUST return 4xx (409) when modifying protected resource statements
- MUST return info in body about which statements could not be persisted when modifying protected resource statements
- MUST return constrainedBy Link in headers when modifying protected resource statements
- MUST return 2xx if successful
3.7.1 Containment Triples - SHOULD return 409 Conflict if PATCH attempts to update containment triples
3.7.2 Interaction models - MUST return 409 when modifying the interaction model to a type that is not a subtype of the current type
 MAY be supported
3.8.1 Recursive Delete - An implementation that cannot recurse should not advertise DELETE in response to OPTIONS requests for container with contained resources.
- MUST use LDP containment relations for recursive deletion, if recursive deletion is supported
- An implementation must not return a 200 (OK) or 204 (No Content) response unless the entire operation successfully completed.
- An implementation must not emit a message that implies successful DELETE of a resource until the resource has been successfully removed.
Compliance with LDP 5.2.5.1 When a contained LDPR is deleted, the LDPC server must also remove the corresponding containment triple, which has the effect of removing the deleted LDPR from the containing LDPC. Compliance with LDP 5.2.5.2 When a contained LDPR is deleted, and the LDPC server created an associated LDP-RS (see the LDPC POST section), the LDPC server must also delete the associated LDP-RS it created.
3.9 External Binary Content (As of 4/21/18, this section is in the process of being implemented)3.9.1 Advertising External Content Support  3.9.3 GET and HEAD requests to any external LDP-NR must correctly respond to the Want-Digest header defined in [ RFC3230 ].
MUST return message/external-body in Accept-Post header (for each supported access-type param of supported Content-Types) if external binary content is supported- (In response to what?)
- Danny Bernstein: a GET on the resource to be POSTed to I believe.
MUST return 415 for LDP-NR create or update if request has message/external-body and an unsupported access-type, or if external binary content is not supported MUST NOT accept request (return 4xx???) for LDP-NR create or update if request has message/external-body and the server cannot return all the required response headers SHOULD return a Content-Location header for LDP-NR GET or HEAD (read? to match create or update above) with a URI to the content if the server is proxying: (How to query for proxying?) MAY support an expiration parameter (for LDP-NR create or update?) if the request has a message/external-body Content-Type header- Expiration parameter is possibly up in the air now ? possibly replace with "Prefer" header syntax.
SHOULD copy content (for LDP-NR create or update?) if the request has a message/external-body Content-Type header and the expiration parameter is set MUST return 4xx or 5xx (for LDP-NR create or update?) if the request has a message/external-body Content-Type header and the expiration parameter cannot be accommodated MUST return a contrainedBy Link header (for LDP-NR create or update?) if the response status is 4xx: Tested in 3.2 and 3.3- Fedora servers supporting external content MUST include "Accept-External-Content-Handling" header in response to "OPTIONS" request.
- The value of the "Accept-External-Content-Handling" response header MUST be a comma-separated list of supported behaviors (copy|redirect|proxy).
3.9.2 External Content for RDF Resources3.9.1 Referenced RDF content in mandataory LDP serializations 3.89.2 Proxied content vs. redirected content3 Redirected and Proxied External Content - Fedora servers supporting "redirect" or "proxy" external content types MUST correctly respond to the "Want-Digest" header
- A successful response to a
GET and HEAD request for external content with handling of redirect must have status code of either 302 (Found) or 307 (Temporary Redirect)Non-normative section
|