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
•  MUST return info in body about which statements could not be persisted when modifying protected resource statements
•  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

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 adverti 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
• An implementation must not return a 200 (OK) or 204 (N 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 b 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 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.

3.8.1 Depth header ( Danny Bernstein: This section is no longer in the spec.)

•  MUST support a Depth header in the request, if DELETE is implemented
•  MAY support only certain Depth header values: (How to query?)
•  MUST return 400 if request includes Depth header and unsupported Depth header value: (How to query?)
•  MUST use LDP containment relations for recursive deletion, if recursive deletion is supported: (How to query?)

3.9 External Binary Content (As of 4/21/18, this section is in the process of being implemented)

• Fedora servers should support the creation and 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. The handling attribute specifies how the server should handle the external content, and the optional type attribute specifies the media type of the external content.

  Fedora servers that do not support the creation of LDP-NRs with content external to the request entity must reject such requests with a 4xx range status code, and 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 reject with a 4xx range status code requests that include multiplerel="http://fedora.info/definitions/fcrepo#ExternalContent" links.

  Fedora servers must use the handling attribute in the external content link to determine how to process the request. This specification defines the following attibutes and expected behaviors:

  
  

  • 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. See also 3.9.3 Redirected and Proxied External Content.
  • 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. Any Content-Type header in the request should be ignored. 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

• 3.9.3 GET and HEAD requests to any external LDP-NRmust correctly respond to the Want-Digest header defined in [RFC3230].

  • A successful response to a GET and HEAD request for external content with handling of redirectmust have status code of either 302 (Found) or 307 (Temporary Redirect).

•  MUST return message/external-body in Accept-Post header (for each supported access-type param of supported Content-Types) if external binary content is supported
  • (In response to what?)
  • Danny Bernstein: a GET on the resource to be POSTed to I believe.
•  MUST return 415 for LDP-NR create or update if request has message/external-body and an unsupported access-type, or if external binary content is not supported
  • Danny Bernstein: we support message/external-body
•  MUST NOT accept request (return 4xx???) for LDP-NR create or update if request has message/external-body and the server cannot return all the required response headers
•  SHOULD return a Content-Location header for LDP-NR GET or HEAD (read? to match create or update above) with a URI to the content if the server is proxying: (How to query for proxying?)
•  MAY support an expiration parameter (for LDP-NR create or update?) if the request has a message/external-body Content-Type header
  • Expiration parameter is possibly up in the air now ? possibly replace with "Prefer" header syntax.
•  SHOULD copy content (for LDP-NR create or update?) if the request has a message/external-body Content-Type header and the expiration parameter is set
•  MUST return 4xx or 5xx (for LDP-NR create or update?) if the request has a message/external-body Content-Type header and the expiration parameter cannot be accommodated
•  MUST return a contrainedBy Link header (for LDP-NR create or update?) if the response status is 4xx: Tested in 3.2 and 3.3

3.9.1 Referenced RDF content in mandataory LDP serializations

• Non-normative section

3.8.2 Proxied content vs. redirected content

• Non-normative section