Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • API Test Suite: 38c974b
  • fcrepo: 478154bcf
TestConforms to specSuite version (38c974b)Status against fcrepofcrepo version (478154bcf)Notes and issues
3.1.1-A - Container-CreateLDPC
PASS
Implementations must support the creation and management of [LDP] Containers.
3.1.1-B - Container-ldpcContainmentTriples
FAIL
LDP Containers must distinguish [containment triples]
3.1.1-C - Container-ldpcMembershipTriples
FAIL
LDP Containers must distinguish [membership] triples.
3.1.1-D - Container-ldpcMinimalContainerTriples
FAIL
LDP Containers must distinguish [minimal-container] triples.
3.1.2.-A - LDPNR-LDPNRCreationLinkType
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
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.