...
- API Test Suite: 38c974b
- fcrepo: 478154bcf
| Test | Conforms to spec |
|---|
| Notes and issues | |
|---|---|
| 3.1.1-A - Container-CreateLDPC | YES Randall Floyd |
| Implementations must support the creation and management of [LDP] Containers. | |
| 3.1.1-B - Container-ldpcContainmentTriples | YES Randall Floyd |
| LDP Containers must distinguish [containment triples] | |
| 3.1.1-C - Container-ldpcMembershipTriples | YES Randall Floyd |
| LDP Containers must distinguish [membership] triples. | |
| 3.1.1-D - Container-ldpcMinimalContainerTriples | YES Randall Floyd |
| LDP Containers must distinguish [minimal-container] triples. | |
| 3.1.2.-A - LDPNR-LDPNRCreationLinkType | YES Randall Floyd |
| If, in a successful resource creation request, a Link: rel="type" request header specifies the LDP-NR interaction model (http://www.w3.org/ns/ldp#NonRDFSource, regardless of Content-Type: value), then the server should handle subsequent requests to the newly created resource as if it is an LDP-NR. ([LDP] 5.2.3.4 extension) | |
| 3.1.2.-B - LDPNR-LDPNRCreationWrongLinkType | YES Randall Floyd |
| If, in a successful resource creation request, a Link: rel="type" request header specifies the LDP-NR interaction model (http://www.w3.org/ns/ldp#NonRDFSource, regardless of Content-Type: value), then the server should handle subsequent requests to the newly created resource as if it is an LDP-NR. ([LDP] 5.2.3.4 extension) |
| 3.2.1-A - HttpGet-AdditionalValuesForPreferHeader |
| In addition to the requirements of [LDP], an implementation may support the value http://www.w3.org/ns/oa#PreferContainedDescriptions and should support the value http://fedora.info/definitions/fcrepo#PreferInboundReferences for the Prefer header when making GET requests on LDPC resources. | |
| 3.2.2-A - HttpGet-LDPRS-ResponsePreferenceAppliedHeader |
| Responses to GET requests that apply a Prefer request header to any LDP-RS must include the Preference-Applied response header as defined in [RFC7240] section 3. | |
| 3.2.2-B - HttpGet-LDPRS-ResponseDescribesHeader |
| When a GET request is made to an LDP-RS that describes an associated LDP-NR (3.5 HTTP POST and [LDP]5.2.3.12),the response must include a Link: rel="describes" header referencing the LDP-NR in question, as defined in [RFC6892]. | |
| 3.2.3-A - HttpGet-RespondWantDigest |
| Testing for supported digest GET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230] | |
| 3.2.3-B - HttpGet-RespondWantDigestTwoSupported |
| Testing for two supported digests with no weights GET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230] | ||
| 3.2.3-C - HttpGet-RespondWantDigestTwoSupportedQvalueNonZero |
| Testing for two supported digests with different weightsGET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230] | ||
| 3.2.3-D - HttpGet-RespondWantDigestTwoSupportedQvalueZero |
| Testing for two supported digests with different weights q=0.3,q=0 GET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230] | |
| 3.2.3-E - HttpGet-RespondWantDigestNonSupported |
| Testing for one supported digest and one unsupported digest.GET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230] | |
| 3.3-A - HttpHead-ResponseNoBody |
| The HEAD method is identical to GET except that the server must not return a message-body in the response, as specified in [RFC7231] section 4.3.2. | ||
| 3.3-B - HttpHead-ResponseDigest |
| The server must send the same Digest header in the response as it would have sent if the request had been a GET (or omit it if it would have been omitted for a GET). | ||
| 3.3-C - HttpHead-ResponseHeadersSameAsHttpGet |
| In other cases, The server should send the same headers in response to a HEAD request as it would have sent if the request had been a GET, except that the payload headers (defined in [RFC7231] section 3.3) may be omitted. | |
| 3.4-A - HttpOptions-HttpOptionsSupport |
| Any LDPR must support OPTIONS per [LDP] 4.2.8. 4.2.8.1 LDP servers must support the HTTP OPTIONS method. | |
| 3.4-B - HttpOptions-HttpOptionsSupportAllow |
| Any LDPR must support OPTIONS per [LDP] 4.2.8. LDP servers must indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow. | |
| 3.5-A - HttpPost |
| Any LDPC (except Version Containers (LDPCv)) must support POST ([LDP] 4.2.3 / 5.2.3). | |
| 3.5-B - HttpPost-ConstrainByResponseHeader |
| The default interaction model that will be assigned when there is no explicit Link header in the request must be recorded in the constraints document referenced in the Link: rel="http://www.w3.org/ns/ldp#constrainedBy" header ([LDP] 4.2.1.6 clarification). | |
| 3.5-C - NonRDFSource-PostNonRDFSource |
| Any LDPC must support creation of LDP-NRs on POST ([LDP] 5.2.3.3 may becomes must). | ||
| 3.5-D - NonRDFSource-PostResourceAndCheckAssociatedResource |
| On creation of an LDP-NR, an implementation must create an associated LDP-RS describing that LDP-NR ([LDP] 5.2.3.12 may becomes must). | |
| 3.5.1-A - NonRDFSource-PostDigestResponseHeaderAuthentication |
| An HTTP POST request that would create an LDP-NR and includes a Digest header (as described in [RFC3230]) for which the instance-digest in that header does not match that of the new LDP-NR must be rejected with a 409 Conflict response. | ||
| 3.5.1-B - NonRDFSource-PostDigestResponseHeaderVerification |
| An HTTP POST request that includes an unsupported Digest type (as described in [RFC3230]), should be rejected with a 400 Bad Request response. | ||
| 3.6-B - HttpPut |
| When accepting a PUT request against an existant resource, an HTTP Link: rel="type" header may be included. If that type is a value in the LDP namespace and is not either a current type of the resource or a subtype of a current type of the resource, the request must be rejected with a 409 Conflict response. | ||
| 3.6.1-A - HttpPut-UpdateTriples |
| Any LDP-RS must support PUT to update statements that are not server-managed triples (as defined in [LDP] 2). [LDP] 4.2.4.1 and 4.2.4.3 remain in effect. | |
| 3.6.1-B - HttpPut-UpdateDisallowedTriples |
| If an otherwise valid HTTP PUT request is received that attempts to modify resource statements that a server disallows (not ignores per [LDP] 4.2.4.1), the server must fail the request by responding with a 4xx range status code (e.g. 409 Conflict). | |
| 3.6.1-C - HttpPut-UpdateDisallowedTriplesResponse |
| The server must provide a corresponding response body containing information about which statements could not be persisted. ([LDP] 4.2.4.4 shouldbecomes must). | |
| 3.6.1-D - HttpPut-UpdateDisallowedTriplesConstrainedByHeader |
| In that response, the restrictions causing such a request to fail must be described in a resource indicated by a Link: rel="http://www.w3.org/ns/ldp#constrainedBy" response header per [LDP] 4.2.1.6. | |
| 3.6.2-A - HttpPutNR |
| Any LDP-NR must support PUT to replace the binary content of that resource. | |
| 3.6.2-B - NonRDFSource-PutDigestResponseHeaderAuthentication |
| An HTTP PUT request that includes a Digest header (as described in [RFC3230]) for which any instance-digest in that header does not match the instance it describes, must be rejected with a 409 Conflict response. | ||
| 3.6.2-C - NonRDFSource-PutDigestResponseHeaderVerification |
| An HTTP PUT request that includes an unsupported Digest type (as described in [RFC3230]), should be rejected with a 400 (Bad Request) response. | ||
| 3.7-A - HttpPatch-SupportHttpPatch |
| Any LDP-RS must support PATCH ([LDP] 4.2.7 may becomes must). [sparql11-update] must be an accepted content-type for PATCH. | |
| 3.7-B - HttpPatch-LDPPatchContentTypeSupport |
| Other content-types (e.g. [ldpatch]) may be available. | ||
| 3.7-C - HttpPatch-ServerManagedPropertiesModification |
| If an otherwise valid HTTP PATCH request is received that attempts to modify statements to a resource that a server disallows (not ignores per [LDP] 4.2.4.1), the server must fail the request by responding with a 4xx range status code (e.g. 409 Conflict). | ||
| 3.7-D - HttpPatch-StatementNotPersistedResponseBody |
| The server must provide a corresponding response body containing information about which statements could not be persisted. ([LDP] 4.2.4.4 should becomes must). | ||
| 3.7-E - HttpPatch-StatementNotPersistedConstrainedByHeader |
| In that response, the restrictions causing such a request to fail must be described in a resource indicated by a Link: rel="http://www.w3.org/ns/ldp#constrainedBy" response header per [LDP] 4.2.1.6. | ||
| 3.7-F - HttpPatch-SuccessfulPatchStatusCode |
| A successful PATCH request must respond with a 2xx status code; the specific code in the 2xx range may vary according to the response body or request state. | |
| 3.7.1 - HttpPatch-DisallowPatchContainmentTriples |
| The server should not allow HTTP PATCH to update an LDPC’s containment triples; if the server receives such a request, it should respond with a 409 (Conflict) status code. | ||
| 3.7.2 - HttpPatch-DisallowChangeResourceType |
| The server must disallow a PATCH request that would change the LDP interaction model of a resource to a type that is not a subtype of the current resource type. That request must be rejected with a 409 Conflict response. | |
| 3.8.1-A - httpDeleteOptionsCheck |
| An implementation that cannot recurse should not advertise DELETE in response to OPTIONS requests for containers with contained resources. | |
| 3.8.1-C - httpDeleteStatusCheck |
| An implementation must not return a 200 (OK) or 204 (No Content) response unless the entire operation successfully completed. | |
| 3.8.1-D - httpDeleteStatusCheckTwo |
| An implementation must not emit a message that implies the successful DELETE of a resource until the resource has been successfully removed. | ||
| 3.9-A - ExternalBinaryContent-PostCreate |
| Fedora servers should support the creation of LDP-NRs with Content-Type of message/external-body and access-type parameter of url. | |
| 3.9-A - ExternalBinaryContent-PutCreate |
| Fedora servers should support the creation of LDP-NRs with Content-Type of message/external-body and access-type parameter of url. | ||
| 3.9-A - ExternalBinaryContent-PutUpdate |
| Fedora servers should support the creation of LDP-NRs with Content-Type of message/external-body and access-type parameter of url. | ||
| 3.9-B - ExternalBinaryContent-createExternalBinaryContentCheckAccesType |
| Fedora servers must advertise support in the Accept-Post response header for each supported access-type parameter value of Content-Type: message/external-body. | |
| 3.9-C - ExternalBinaryContent-PostCheckUnsupportedMediaType |
| Fedora servers receiving requests that would create or update a LDP-NR with a message/external-body with an unsupported type parameter must respond with HTTP 415 UNSUPPORTED MEDIA TYPE. In the case that a Fedora server does not support external LDP-NR content, all message/external-body messages must be rejected with HTTP 415. | |
| 3.9-C - ExternalBinaryContent-PutCheckUnsupportedMediaType |
| Fedora servers receiving requests that would create or update a LDP-NR with a message/external-body with an unsupported type parameter must respond with HTTP 415 UNSUPPORTED MEDIA TYPE. In the case that a Fedora server does not support external LDP-NR content, all message/external-body messages must be rejected with HTTP 415. | |
| 3.9-D - ExternalBinaryContent-checkUnsupportedMediaType |
| In the case that a Fedora server does not support external LDP-NR content, all message/external-body messages must be rejected with 415 (Unsupported Media Type). | ||
| 3.9-E - ExternalBinaryContent-postCheckHeaders |
| Fedora servers receiving requests that would create or update an LDP-NR with Content-Type: message/external-body must not accept the request if it cannot guarantee all. of the response headers required by the LDP-NR interaction model in this specification. | |
| 3.9-E - ExternalBinaryContent-putUpdateCheckHeaders |
| Fedora servers receiving requests that would create or update an LDP-NR with Content-Type: message/external-body must not accept the request if it cannot guarantee all. of the response headers required by the LDP-NR interaction model in this specification. | ||
| 3.9-F - ExternalBinaryContent-HttpGetCheckContentLocationHeader |
| GET and HEAD responses for any external LDP-NR should include a Content-Location header with a URI representation of the location of the external content if the Fedora server is proxying the content. | ||
| 3.9-F - ExternalBinaryContent-HttpHeadCheckContentLocationHeader |
| GET and HEAD responses for any external LDP-NR should include a Content-Location header with a URI representation of the location of the external content if the Fedora server is proxying the content. | |
| 3.9-G - ExternalBinaryContent-respondWantDigestExternalBinaryContent |
| GET and HEAD requests to any external LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230]. | ||
| 3.9-G - ExternalBinaryContent-respondWantDigestExternalBinaryContent |
| GET and HEAD requests to any external LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230]. | ||
| 3.9-H - ExternalBinaryContent-respondWantDigestTwoSupportedExternalBinaryContent |
| GET and HEAD requests to any external LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230]. With two supported digests. | ||
| 3.9-H - ExternalBinaryContent-respondWantDigestTwoSupportedExternalBinaryContent |
| GET and HEAD requests to any external LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230]. With two supported digests. | |
| 3.9-I - ExternalBinaryContent-respondWantDigestTwoSupportedQvalueNonZeroExternalBinaryContent |
| GET and HEAD requests to any external LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230]. Two digests with different weights, q values. | ||
| 3.9-I - ExternalBinaryContent-respondWantDigestTwoSupportedQvalueNonZeroExternalBinaryContentHead |
| GET and HEAD requests to any external LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230]. Two digests with different weights, q values. | ||
| 3.9-J - ExternalBinaryContent-respondWantDigestNonSupportedExternalBinaryContent |
| GET and HEAD requests to any external LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230]. One supported and an unsupported Digest. | |
| 3.9-J - ExternalBinaryContent-respondWantDigestNonSupportedExternalBinaryContentHead |
| GET and HEAD requests to any external LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230]. One supported and an unsupported Digest. |