...
Test | Conforms to spec | Suite version (38c974b) | Status against fcrepo | fcrepo version (478154bcf) | Notes and issues |
---|---|---|---|---|---|
3.1.1-A - Container-CreateLDPC | YES | PASS | Implementations must support the creation and management of [LDP] Containers. | ||
3.1.1-B - Container-ldpcContainmentTriples | YES | FAIL | LDP Containers must distinguish [containment triples] | ||
3.1.1-C - Container-ldpcMembershipTriples | YES | FAIL | LDP Containers must distinguish [membership] triples. | ||
3.1.1-D - Container-ldpcMinimalContainerTriples | YES | FAIL | LDP Containers must distinguish [minimal-container] triples. | ||
3.1.2.-A - LDPNR-LDPNRCreationLinkType | YES | PASS | 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 | PASS | 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 | PASS | 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 | PASS | 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 | PASS | 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 | PASS | 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 | FAIL | 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 | FAIL | 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 | PASS | 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 | PASS | 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 | PASS | 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 | PASS | 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 | FAIL | 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 | PASS | 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 | PASS | 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 | PASS | Any LDPC (except Version Containers (LDPCv)) must support POST ([LDP] 4.2.3 / 5.2.3). | |||
3.5-B - HttpPost-ConstrainByResponseHeader | PASS | 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 | PASS | Any LDPC must support creation of LDP-NRs on POST ([LDP] 5.2.3.3 may becomes must). | |||
3.5-D - NonRDFSource-PostResourceAndCheckAssociatedResource | PASS | 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 | PASS | 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 | PASS | 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 | FAIL | 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 | PASS | 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 | PASS | 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 | PASS | 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 | PASS | 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 | PASS | Any LDP-NR must support PUT to replace the binary content of that resource. | |||
3.6.2-B - NonRDFSource-PutDigestResponseHeaderAuthentication | PASS | 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 | PASS | 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 | PASS | 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 | FAIL | Other content-types (e.g. [ldpatch]) may be available. | |||
3.7-C - HttpPatch-ServerManagedPropertiesModification | PASS | 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 | PASS | 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 | PASS | 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 | PASS | 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 | PASS | 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 | FAIL | 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 | PASS | An implementation that cannot recurse should not advertise DELETE in response to OPTIONS requests for containers with contained resources. | |||
3.8.1-C - httpDeleteStatusCheck | PASS | An implementation must not return a 200 (OK) or 204 (No Content) response unless the entire operation successfully completed. | |||
3.8.1-D - httpDeleteStatusCheckTwo | PASS | 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 | PASS | 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 | FAIL | 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 | PASS | 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 | PASS | 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 | PASS | 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 | PASS | 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 | PASS | 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 | PASS | 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 | PASS | 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 | FAIL | 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 | FAIL | 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 | FAIL | 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 | FAIL | 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 | FAIL | 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 | FAIL | 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 | FAIL | 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 | FAIL | 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 | FAIL | 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 | FAIL | 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. |
...