...
| Test | Specification as reported by test | Conforms to spec | Notes and issues |
|---|---|---|---|
| 3.1.1-A - Container-CreateLDPC (Code) | Implementations must support the creation and management of [LDP] Containers. | YES Randall Floyd | |
| 3.1.1-B - Container-ldpcContainmentTriples (Code) | LDP Containers must distinguish [containment triples] | YES Randall Floyd | |
| 3.1.1-C - Container-ldpcMembershipTriples (Code) | LDP Containers must distinguish [membership] triples. | YES Randall Floyd | |
| 3.1.1-D - Container-ldpcMinimalContainerTriples (Code) | LDP Containers must distinguish [minimal-container] triples. | YES Randall Floyd | |
| 3.1.2.-A - LDPNR-LDPNRCreationLinkType (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) | YES Randall Floyd | The test is valid but printing of header values to the logs on POST would aid in troubleshooting. |
| 3.1.2.-B - LDPNR-LDPNRCreationWrongLinkType (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) | YES Randall Floyd | |
| 3.2.1-A - HttpGet-AdditionalValuesForPreferHeader (Code) | 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. | YES Randall Floyd | |
| 3.2.2-A - HttpGet-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. | YES Randall Floyd | |
| 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]. | YES Randall Floyd | |
| 3.2.3-A - HttpGet-RespondWantDigest (Code) | Testing for supported digest GET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230] | YES Randall Floyd | |
| 3.2.3-B - HttpGet-RespondWantDigestTwoSupported (Code) | 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] | YES Randall Floyd | |
| 3.2.3-C - HttpGet-RespondWantDigestTwoSupportedQvalueNonZero (Code) | Testing for two supported digests with different weightsGET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230] | YES Randall Floyd | |
| 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] | YES Randall Floyd | |
| 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] | YES Randall Floyd | |
| 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. |
...