fcrepo4-labs/derby

A pure Ruby Fedora Commons implementation.

derby's Issues

FCR API must define PUT-to-create-objects

4.2.4.6 LDP servers may choose to allow the creation of new resources using HTTP PUT.

Obviously, FCR API needs a stronger requirement.

Should FCR API Guarantee Slug Behavior on POST?

Both Derby and FCRepo4 currently respect Slug: headers on HTTP POST requests, failing the request if the requested slug can't be applied.

This behavior provides a safe mechanism for clients to request a new resource with a known URI within a given container. PUT can provide a similar mechanism, but only with a more complex set of assumptions about the containment of resources created with PUT requests. The slug approach feels more general.

@tpendragon, @cbeer and I ran into this while testing ActiveFedora with Derby, and had the sense that POST was the best approach for clients aiming for generalized LDP support.

Derby should not show a stack trace when GET on a resource that doesn't exist.

Returning a 404 status should be sufficient.

NoMethodError: undefined method `new_offset' for nil:NilClass

$ curl -X PUT "http://localhost:4567/basic" -H "Link: <http://www.w3.org/ns/ldp#BasicContainer>;rel=\"type\"" -d "" -H "Content-Type: text/turtle"
$ curl -v "http://localhost:4567/basic"
...
< HTTP/1.1 200 OK
$ curl -v "http://localhost:4567/basic/"
...
< HTTP/1.1 500 Internal Server Error 
NoMethodError: undefined method `new_offset' for nil:NilClass
    /Users/cabeer/.gem/ruby/2.2.3/gems/rdf-ldp-0.4.0/lib/rdf/ldp/resource.rb:305:in `etag'
    /Users/cabeer/.gem/ruby/2.2.3/gems/rdf-ldp-0.4.0/lib/rdf/ldp/resource.rb:492:in `update_headers'
    /Users/cabeer/.gem/ruby/2.2.3/gems/rdf-ldp-0.4.0/lib/rdf/ldp/resource.rb:436:in `options'
    /Users/cabeer/.gem/ruby/2.2.3/gems/rdf-ldp-0.4.0/lib/rdf/ldp/resource.rb:410:in `request'

Should `fcrepo` API Allow `200` in PATCH Responses?

Clients (ActiveFedora) currently rely on a 204 response to PATCH requests. Is this a bug in the clients and documentation, or does the API genuinely want to restrict to 204, ruling out other status codes (and their associated behaviors).

This is being raised due to #13.

500 error on PATCH with sparql-update

I admit that I'm relatively green when it comes to LDP, so I might be missing something from the client side. But given that this is an interaction between ActiveFedora -> LDP -> Derby, I don't think it's anything I'm doing. At any rate, if the sparql-update is bad, I'd expect a 4xx at worst.

Trying to save a new Avalon::Collection descendant for the first time. The initial POST works fine, but it's immediately followed by a PATCH that blows up:

::1 - - [07/Oct/2016:23:19:37 -0500] "POST /rest/development HTTP/1.1" 201 - 0.0092
::1 - - [07/Oct/2016:23:19:37 -0500] "HEAD /rest/development/3f17c037-1282-4200-83b0-b7c0207eed23 HTTP/1.1" 200 - 0.0024
::1 - - [07/Oct/2016:23:19:37 -0500] "GET /rest/development/3f17c037-1282-4200-83b0-b7c0207eed23 HTTP/1.1" 200 - 0.0063
::1 - - [07/Oct/2016:23:19:37 -0500] "HEAD /rest/development/20b3bc2b-929a-4341-82a3-aca77dcb7d31 HTTP/1.1" 200 - 0.0016
::1 - - [07/Oct/2016:23:19:37 -0500] "GET /rest/development/20b3bc2b-929a-4341-82a3-aca77dcb7d31 HTTP/1.1" 200 - 0.0049
::1 - - [07/Oct/2016:23:19:37 -0500] "PATCH /rest/development/20b3bc2b-929a-4341-82a3-aca77dcb7d31 HTTP/1.1" 500 144778 0.0553

The request body looks like this:

DELETE { <> <http://purl.org/dc/terms/title> ?change . }
  WHERE { <> <http://purl.org/dc/terms/title> ?change . } ;
DELETE { <> <http://bibframe.org/vocab/heldBy> ?change . }
  WHERE { <> <http://bibframe.org/vocab/heldBy> ?change . } ;
DELETE { <> <http://www.w3.org/ns/auth/acl#accessControl> ?change . }
  WHERE { <> <http://www.w3.org/ns/auth/acl#accessControl> ?change . } ;
DELETE { <> <http://avalonmediasystem.org/rdf/vocab/collection#dropbox_directory_name> ?change . }
  WHERE { <> <http://avalonmediasystem.org/rdf/vocab/collection#dropbox_directory_name> ?change . } ;
DELETE { <> <http://avalonmediasystem.org/rdf/vocab/collection#default_visibility> ?change . }
  WHERE { <> <http://avalonmediasystem.org/rdf/vocab/collection#default_visibility> ?change . } ;
DELETE { <> <http://projecthydra.org/ns/auth/acl#defaultPermissions> ?change . }
  WHERE { <> <http://projecthydra.org/ns/auth/acl#defaultPermissions> ?change . } ;
INSERT {
<> <http://purl.org/dc/terms/title> "foo" .
<> <http://bibframe.org/vocab/heldBy> "Default Unit" .
<> <http://www.w3.org/ns/auth/acl#accessControl> <http://localhost:9292/rest/development/b88e7057-824f-471c-a850-bdebf4e8849f> .
<> <http://avalonmediasystem.org/rdf/vocab/collection#dropbox_directory_name> "foo" .
<> <http://avalonmediasystem.org/rdf/vocab/collection#default_visibility> "private" .
<> <http://projecthydra.org/ns/auth/acl#defaultPermissions> <http://localhost:9292/rest/development/3f17c037-1282-4200-83b0-b7c0207eed23> .
}
 WHERE { }

(unfortunately I was unable to capture the request headers)

The error that comes back is #<RDF::Query::Pattern:0x3ffd025e33c0(<> <http://purl.org/dc/terms/title> ?change .)> is not valid

I've added what I think is a reasonable approximation of a failing test in my fork: mbklein/derby@c1553d3