Versions Compared

Key

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

...

Expand

3.1 General (Jared Whiklo)

  • Empty section

3.1.1 LDP Containers

  • (tick) MUST be able to create LDP Containers: Tested in 3.3
  • (tick)  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.
  • (minus) MAY permit ldp:contains membership predicate if server can distinguish between triple types
  • (minus) SHOULD allow Prefer header in request to distinguish triple types if server can distinguish triple types

3.1.2 LDP-NR creation

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

3.1.3 Constraints Document

3.1.4 Data Model

3.2 HTTP GET

3.2.1 Additional values for the Prefer header

3.2.2 LDP-RSs

  • (tick) 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(tick), some invalid (error)
  • (tick) MUST return describes Link to LDP-NR if request is to associated LDP-RS

3.2.3 LDP-NRs

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

3.3 HTTP HEAD

  • (tick) MUST NOT return a body
  • (tick) SHOULD return same headers as if the request was a GET
    • (tick) Almost perfect: Binary resources have duplicate headers that are not seen on HEAD
      Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyFCREPO-2714
  • (tick) MUST return a Digest header if the same request as a GET would have
  • (minus) MAY omit payload headers from response

3.4 HTTP OPTIONS (Yinlin Chen)

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

3.5 HTTP POST

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

3.5.1 LDP-NRs

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

3.6 HTTP PUT

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

3.6.1 LDP-RSs

  • (tick) MUST support PUT on LDP-RSs for non-server-managed triples
  • (tick)  MUST return 4xx (409) if request modifies server-managed triples on a LDP-RS
  • (tick) MUST return constrainedBy Link in headers if request modifies server-managed triples on a LDP-RS
  • (tick) 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, which is fine

3.6.2 LDP-NRs (Danny Bernstein)

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

3.6.3 Creating resources with HTTP PUT

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

3.7 HTTP PATCH (Jared Whiklo)

  • (tick) MUST be supported on LDP-RSs
  • (tick) MUST support Content-Type: application/sparql-update
  • (minus) MAY support other update types
  • (tick) MUST return 4xx (409) when modifying protected resource statements
    • Tested by attempting to add "fedora:lastModifiedBy" property to a container via PATCH
  • (tick) MUST return info in body about which statements could not be persisted when modifying protected resource statements
  • (tick) MUST return constrainedBy Link in headers when modifying protected resource statements
  • (tick) MUST return 2xx if successful

3.7.1 Containment Triples

3.7.2 Interaction models

  • (tick) 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)

  • (warning) MAY be supported

3.8.1 Recursive Delete

  • (tick) An implementation that cannot recurse should not advertise DELETE in response to OPTIONS requests for container with contained resources. 
  • (tick) 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
  • (tick) An implementation must not return a 200 (OK) or 204 (No Content) response unless the entire operation successfully completed. 
  • (tick) An implementation must not emit a message that implies successful DELETE of a resource until the resource has been successfully removed. 
  • (tick) 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.
  • (tick)  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

  • (tick) 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.

    • (tick) handling="copy"
    • (tick)handling="redirect"
    • (tick)handling="proxy"
  • (tick) 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.

    • (tick) handling="redirect"
    • (tick) handing="copy"
    • (tick) handling="proxy"
  • (minus) Fedora servers that do not support the creation of LDP-NRs with content external must reject with a 4xx range status code
  • (minus) 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.

  • (tick)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

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

      • (tick) 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.

      • (tick) 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 .

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

  • (tick)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.

  • (tick)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.
  • (tick) Fedora servers should ignore any  Content-Type  header in the request .
    • (tick) no "type=" attribute in the Link header results in 'application/octet-stream'
    • (tick) "type=" as well as 'Content-Type' header result in "type=" taking precedence
    • (tick) no "type=", but with 'Content-Type' results in 'Content-Type' being ignored (as it should be)
  • If there is no  type  attribute:
    • (minus)   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).
    • (tick) Servers may use a default media type.
      • server uses default content type of "application/octet-stream"
    • (minus)   Servers may reject the request with a 4xx range status code.
  • (tick) 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
    • Required "describedby" Link header present for all non-historic-memento
      • (error) (tick)Image AddedHistoric mementos of external binaries are currently failing, so cannot confirm behavior for historic mementos (although they most likely will violate the Link requirement after the historic binary has been created but not the historic description):

        Code Block
        curl -i -XPOSTXPUT -H "Slug:logov" -H "Link: <http://mementoweb.org/ns#OriginalResource>; rel=\"type\"" -H "Link: <https://duraspace.org/wp-content/themes/duraspace/assets/images/whitedura.png>; rel=\"http://fedora.info/definitions/fcrepo#ExternalContent\"; handling=\"proxy\"; type=\"image/png\"" "http://localhost:8080/rest/coollogo" -ufedoraAdmin:fedoraAdmin
        
        curl -XPOST http://localhost:8080/rest/logovcoollogo/fcr:versions -H "Memento-Datetime: Sat, 1 Jan 2000 00:00:00 GMT" -H "Link: <https://wiki.duraspace.org/download/attachments/31655033/fedora_logo_2in.png>; rel=\"http://fedora.info/definitions/fcrepo#ExternalContent\"; handling=\"proxy\"; type=\"image/png\"" -ufedoraAdmin:fedoraAdmin
        
        #Response:
        # < HTTP/1.1 415 Unsupported Media Type
        # Invalid Content Type application/octet-stream


      • Jira
        serverDuraSpace JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyFCREPO-2815

    • Server provides a default "application/octet-stream" Content-type if one is not determined from a proxied or redirected resource
      • Confirmed for copy, redirect and proxy HTTP URLs.
    • NOTE: For a proxy binary from a HTTP URL that does not return a Content-Length header, the premis:hasSize property will be set to -1 and no Content-Length header is returned from Fcrepo.

3.9.1 Advertising External Content Support

  • (error) Fedora servers supporting external content MUST include "Accept-External-Content-Handling" header in response to "OPTIONS" request.
    • Jira
      serverDuraSpace JIRA
      columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyFCREPO-2814
      currently only binary resources will return this header on an OPTIONS request. This ticket is to make containers return it as well.
  • (error) The value of the "Accept-External-Content-Handling" response header MUST be a comma-separated list of supported behaviors (copy|redirect|proxy).
    • Jira
      serverDuraSpace JIRA
      columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyFCREPO-2814

3.9.2 External Content for RDF Resources

  • Non-normative section

3.9.3 Redirected and Proxied External Content

  • (tick) Fedora servers supporting "redirect" external content types MUST correctly respond to the "Want-Digest" header
  • (tick) Fedora servers supporting "proxy" external content types MUST correctly respond to the "Want-Digest" header
  • (tick) 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)

...