Test | Specification as reported by test | Conforms to spec | Notes and issues |
---|
Test | Suite Version | Conforms to spec | Status against fcrepo4 | fcrepo Version | Notes |
---|
3.1.1-A - Container-CreateLDPC | 38c974b | PASS | Implementations must support the creation and management of [LDP] Containers. | 3.1.1-B - Container-ldpcContainmentTriples | 38c974b | FAIL | LDP Containers must distinguish [containment triples] | 3.1.1-C - Container-ldpcMembershipTriples | 38c974b | FAIL | LDP Containers must distinguish [membership] triples.D ldpcMinimalContainerTriples38c974b | FAIL | LDP Containers must distinguish [minimal-container] triples. | CreateLDPC (Code) | Implementations must support the creation and management of [LDP] Containers. | |
|
3.1. |
2.A LDPNR-LDPNRCreationLinkType38c974b | 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) | B LDPNRCreationWrongLinkType38c974b | PASSLDPNRCreationLinkType (Code) | 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) | | The test is valid but more consistent printing of header values, as done in 3. |
2.1-A - HttpGet-AdditionalValuesForPreferHeaderFAIL | In addition to the requirements of [LDP], an implementation may support the value http://oa#PreferContainedDescriptions and should support the value http://fedora.info/definitions/fcrepo#PreferInboundReferences for the Prefer header when making GET requests on LDPC resources.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) | | The test is valid but more consistent printing of header values, as done in 3.1.1.* tests, to the logs on POST would aid in troubleshooting |
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 32B LDPRS-ResponseDescribesHeaderPASS | 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-RespondWantDigestPASS | 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 | -LDPRS-ResponsePreferenceAppliedHeader (Code) | 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 (Code) | 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]. | |
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]C FAIL | RespondWantDigestTwoSupportedQvalueNonZero two supported digests with different weightsGET supported digest GET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230] | |
|
3.2.3- |
D RespondWantDigestTwoSupportedQvalueZeroPASS different weights q=0.3,q=0 no weights GET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230] | |
|
3.2.3- |
E RespondWantDigestNonSupportedPASS | one supported digest and one unsupported digest.GET two supported digests with different weightsGET 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 | |
|
3.2.3-D - HttpGet-RespondWantDigestTwoSupportedQvalueZero (Code) | 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 (Code) | 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). | | Appears to have been moved down into 3.5.1. Labels should probably be shifted to reflect this as 3.5.1-A. |
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). | | Appears to have been moved down into 3.5.1. Labels should probably be shifted to reflect this as 3.5.1-B. Conformance issue: It is unclear if the test applied in this line would catch multi valued header fields correctly: https://github.com/fcrepo4-labs/Fedora-API-Test-Suite/blob/master/src/main/java/com/ibr/fedora/testsuite/HttpPost.java#L161 This will work if the multi valued 'Link' field is comma separated, but not if they are truly multiples (FIFO?). For example, Fedora at d7731a086 is failing this test for this reason. Which is correct for multi-valued fields, comma separated or multiple fields? |
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. | | Since 3.5-C and D should be 3.5.1-A and 3.5.1-B, this should be 3.5.1-C. |
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. | | Since 3.5-C and D should be 3.5.1-A and 3.5.1-B, this should be 3.5.1-D. |
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 |
PASSPASS | 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 |
PASSPASSPASSPASSPASS | 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 |
PASSFAILPASS | 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 |
PASSPASS | PASSPASSFAIL | 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 |
to a type that is not a subtype of the current resource type. That request must be rejected with a 409 Conflict response.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. | | I don't understand the test as written, especially compared with the Fedora responses under test, but that doesn't mean it isn't valid. A second opinion would be appreciated |
3.8.1-A - httpDeleteOptionsCheck | PASS | An implementation that cannot recurse should not advertise DELETE in response to OPTIONS requests for containers with contained resourcesPASS | PASSPASSFAILPASSPASS | 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 |
PASSPASS | 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 |
FAILFAIL | FAILFAILFAILFAILFAIL | FAILFAIL | 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. |
|
|