Page History

3.1 General (Jared Whiklo)

• Empty section

3.1.1 LDP Containers

• MUST be able to create LDP Containers: Tested in 3.3
•   MUST distinguish between triple types OR MUST return 409 with constrainedBy Link in headers for ldp:contains membership predicate if server cannot distinguish between triple types
  • We return a 409 because we can't distinguish and therefore the next 2 tests are not applicable.
• MAY permit ldp:contains membership predicate if server can distinguish between triple types
•  SHOULD allow Prefer header in request to distinguish triple types if server can distinguish triple types

3.1.2 LDP-NR creation

•  SHOULD create an LDP-NR if creation request includes NonRDFSource type Link in headers, regardless of Content-Type headers

3.1.3 Constraints Document

• SHOULD respond with <Link: http://www.w3.org/ns/ldp#constrainedBy> header on failures due to implementation choices

3.1.4 Data Model

• MUST respond with <Link: http://www.w3.org/ns/ldp#constrainedBy > header on failures due to unallowed data model ... like single-subject-restriction scenario

3.2 HTTP GET

3.2.1 Additional values for the Prefer header

•  SHOULD support PreferInboundReferences URI in Prefer header
  
  • Supports the old " http://fedora.info/definitions/v4/repository#InboundReferences " but not the one defined in the spec.
•  MAY support PreferContainedDescriptions URI in Prefer header

3.2.2 LDP-RSs

•  MUST return Preference-Applied header if request's Prefer header is honored (Always applied)
  • note: also test with a combinations of Prefer headers: some valid, some invalid
•  MUST return describes Link to LDP-NR if request is to associated LDP-RS

3.2.3 LDP-NRs

•  MUST return Digest header as directed by request's Want-Digest header

3.3 HTTP HEAD

•  MUST NOT return a body
•  SHOULD return same headers as if the request was a GET
  • Almost perfect: Binary resources have duplicate headers that are not seen on HEAD

    Jira
    server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2714

•  MUST return a Digest header if the same request as a GET would have
•  MAY omit payload headers from response

3.4 HTTP OPTIONS (Yinlin Chen)

• Any LDPR must support OPTIONS per [LDP] 4.2.8. 4.2. LDP servers must support the HTTP OPTIONS method. 

3.5 HTTP POST

•  MUST be supported on LDPC
• MAY not be supported on LDPCv
•  MUST include default interaction model in constrainedBy Link header
  
  • Correct for both LDP-RS and LDP-NR

3.5.1 LDP-NRs

•  MUST support creation of LDP-NRs
•  MUST create and associate an LDP-RS when an LDP-NR is created
•  MUST return 409 if request Digest header does not match calculated value for content of new LDP-NR
•  SHOULD return 400 if request Digest header's type is not supported (Should 'type' be 'algorithm', like the RFC?)

3.6 HTTP PUT

•  MAY include type Link header in request
•  SHOULD return 409 if request's type Link is not resource's current type or subtype thereof, or not in LDP namespace
• MUST change resource's type if request's type Link is a subtype of resource's current type
• MUST change resource's interaction model if request's type Link has an LDP interaction model

3.6.1 LDP-RSs

•  MUST support PUT on LDP-RSs for non-server-managed triples
•  MUST return 4xx (409) if request modifies server-managed triples on a LDP-RS
• MUST return constrainedBy Link in headers if request modifies server-managed triples on a LDP-RS
• MUST return info in body about which statements could not be persisted if request modifies server-managed triples on a LDP-RS
• Currently we allow the use of the -Dfcrepo.properties.management=relaxed option to allow updating server managed triples.

3.6.2 LDP-NRs (Danny Bernstein)

•  MUST support PUT on LDP-NRs to replace binary content
•  MUST return 409 if request Digest header does not match calculated value for new content of target LDP-NR
•  SHOULD return 400 if request Digest header's type is not supported

3.6.3 Creating resources with HTTP PUT

• If PUT is supported for creation of LDP-NRs, MUST create and associate an LDP-RS when an LDP-NR is created

3.7 HTTP PATCH (Jared Whiklo)

•  MUST be supported on LDP-RSs
•  MUST support Content-Type: application/sparql-update
•  MAY support other update types
•  MUST return 4xx (409) when modifying protected resource statements
  • Tested by attempting to add "fedora:lastModifiedBy" property to a container via PATCH
•  MUST return info in body about which statements could not be persisted when modifying protected resource statements
  • Returns "Could not persist triple containing predicate http://fedora.info/definitions/v4/repository#lastModifiedBy to node /test_container"
•  MUST return constrainedBy Link in headers when modifying protected resource statements
•  MUST return 2xx if successful

3.7.1 Containment Triples

•  SHOULD return 409 Conflict if PATCH attempts to update containment triples
  • Tested by attempting to add "ldp:contains" relation referencing another LDPR via PATCH.
  • Rejected with status 409
  • Link: <http://localhost:8080/static/constraints/ServerManagedPropertyException.rdf>; rel="http://www.w3.org/ns/ldp#constrainedBy"
  • Could not persist triple containing predicate http://www.w3.org/ns/ldp#contains to node /test_container

3.7.2 Interaction models

•  MUST return 409 when modifying the interaction model to a type that is not a subtype of the current type

3.8 HTTP DELETE (Yinlin Chen)

•  MAY be supported

3.8.1 Recursive Delete

• An implementation that cannot recurse should not advertise DELETE in response to OPTIONS requests for container with contained resources. 
•  MUST use LDP containment relations for recursive deletion, if recursive deletion is supported
  • NOTE: Contained resource and all subresources were return the tombstone of the root resource deleted
• An implementation must not return a 200 (OK) or 204 (No Content) response unless the entire operation successfully completed. 
• An implementation must not emit a message that implies successful DELETE of a resource until the resource has been successfully removed. 

•  Compliance with LDP 5.2.5.1 When a contained LDPR is deleted, the LDPC server must also remove the corresponding containment triple, which has the effect of removing the deleted LDPR from the containing LDPC.

•  Compliance with LDP 5.2.5.2 When a contained LDPR is deleted, and the LDPC server created an associated LDP-RS (see the LDPC POST section), the LDPC server must also delete the associated LDP-RS it created.

  • LDP-NR and associated LDP-RS both return 410
  • Confirm LDP-NR and LDP-RS both return 410 after being deleted recursively

3.9 External Binary Content

• Fedora servers should support the creation of LDP-NRs with content external to the request entity, as indicated by a link with rel="http://fedora.info/definitions/fcrepo#ExternalContent" and target that is the location of the external content.

  • handlingcopy handling="copy"

• Fedora servers should support the update of LDP-NRs with content external to the request entity, as indicated by a link with rel="http://fedora.info/definitions/fcrepo#ExternalContent" and target that is the location of the external content.

• Fedora servers that do not support the creation of LDP-NRs with content external must reject with a 4xx range status code

• Fedora servers that do not support the creation of LDP-NRs with content external must describe this restriction in a resource indicated by a rel="http://www.w3.org/ns/ldp#constrainedBy" link in the Link response header.

• Fedora servers must use the handling attribute in the external content link to determine how to process the request.

  • At least one of the following handling attributes must be supported

    • copy - requests that the server dereference the external content URI and treat that as if it were the entity body of the request.

    • redirect - requests that the server record the location of the external content and handle requests for that content using HTTP redirect responses with the Content-Location header specifying the external content location.

    • proxy - requests that the server record the location of the external content and handle requests for that content by proxying. See also  3.9.3 Redirected and Proxied External Content .

• Fedora servers must reject with a 4xx range status code requests for which the handling attribute is not present or cannot be respected.

• In the case that the specified handling cannot be respected, the restrictions causing the request to fail must be described in a resource indicated by a rel="http://www.w3.org/ns/ldp#constrainedBy" link in the Link response header.

• Fedora servers must use the value of the type attribute in the external content link as the media type of the external content, if provided.
• Fedora servers should ignore any Content-Type header in the request.
• If there is no type attribute:
  • Servers may use the media type obtained when accessing the external content via the specified scheme (e.g. the Content-Type header for external content accessed via http).
  • Servers may use a default media type.
  • Servers may reject the request with a 4xx range status code.
• A Fedora server receiving requests that would create or update an LDP-NR with content external to the request entity must reject request if it cannot guarantee all of the response headers required by the LDP-NR interaction model in this specification

3.9.1 Advertising External Content Support

• Fedora servers supporting external content MUST include "Accept-External-Content-Handling" header in response to "OPTIONS" request.
• The value of the "Accept-External-Content-Handling" response header MUST be a comma-separated list of supported behaviors (copy|redirect|proxy).

3.9.2 External Content for RDF Resources

• Non-normative section

3.9.3 Redirected and Proxied External Content

• Fedora servers supporting "redirect" external content types MUST correctly respond to the "Want-Digest" header
• Fedora servers supporting "proxy" external content types MUST correctly respond to the "Want-Digest" header
• A successful response to a GET and HEAD request for external content with handling of redirect must have status code of either 302 (Found) or 307 (Temporary Redirect)