Behavior of Accept header in GET to NonRDFSource URL

7 views
Skip to first unread message

Michael Giarlo

unread,
May 8, 2019, 5:33:32 PM5/8/19
to Trellis LDP
Hi again,

I'm hitting some behavior that surprises me, though again am unsure if it's a corner of LDP I'm less familiar with.

So, I post a new NonRDFSource:

$ curl -iL -X POST -H 'Link: <http://www.w3.org/ns/ldp#NonRDFSource>; rel="type"' -H 'Slug: ResourceTemplate3' -H 'Content-Type: application/json' -d '{ "foo": "bar" }' http://localhost:8080/repository/ld4p
HTTP/1.1 201 Created                                                                                                                                  
Date: Wed, 08 May 2019 20:50:16 GMT                                                                                                                   
Link: <http://platform:8080/repository/ld4p/ResourceTemplate3?ext=description>; rel="describedby"                                                     
Link: <http://www.w3.org/ns/ldp#NonRDFSource>; rel="type"                                                                                             
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"                                                                                                 
Link: <http://platform:8080/repository/ld4p?ext=acl>; rel="acl"                                                                                       
Location: http://platform:8080/repository/ld4p/ResourceTemplate3                                                                                      
Content-Length: 0 

That worked as expected. I issue a GET request to the new resource URI:

HTTP/1.1 200 OK
Date: Wed, 08 May 2019 21:20:17 GMT
Last-Modified: Wed, 08 May 2019 20:50:16 GMT
Vary: Accept
Vary: Accept-Datetime
Vary: Range
Vary: Want-Digest
Link: <http://platform:8080/repository/ld4p/ResourceTemplate3?ext=timemap>; rel="timemap"; from="Wed, 8 May 2019 20:50:16 GMT"; until="Wed, 8 May 2019 20:50:16 GMT"; type="application/link-format"
Link: <http://platform:8080/repository/ld4p/ResourceTemplate3?version=1557348616>; rel="memento"; datetime="Wed, 8 May 2019 20:50:16 GMT"
Content-Type: application/json
Accept-Ranges: bytes
ETag: "30ad7e8bda5dccf3ac6ac930d9aac328"
Allow: GET,HEAD,OPTIONS,PUT,DELETE
Cache-Control: no-transform, must-revalidate, max-age=86400
Vary: Accept-Encoding
Content-Length: 48

{ "foo": "bar", "baz": { "quuux": "whatever" } }

The content looks exactly right and the Link headers return the types I expect. Here's where it gets weird. I issue the GET again, but this time I add the 'Accept: application/ld+json' header:

$ curl -iL -H 'Accept: application/ld+json' http://localhost:8080/repository/ld4p/ResourceTemplate3
HTTP/1.1 200 OK
Date: Wed, 08 May 2019 21:20:57 GMT
Last-Modified: Wed, 08 May 2019 20:50:16 GMT
Vary: Accept
Vary: Prefer
Vary: Accept-Datetime
Content-Type: application/ld+json
Link: <http://platform:8080/repository/ld4p/ResourceTemplate3?ext=timemap>; rel="timemap"; from="Wed, 8 May 2019 20:50:16 GMT"; until="Wed, 8 May 2019 20:50:16 GMT"; type="application/link-format"
Link: <http://platform:8080/repository/ld4p/ResourceTemplate3?version=1557348616>; rel="memento"; datetime="Wed, 8 May 2019 20:50:16 GMT"
Accept-Patch: application/sparql-update
ETag: W/"719b7e15123d6450c13c466289d6f27f"
Allow: GET,HEAD,OPTIONS,PATCH,PUT,DELETE,POST
Cache-Control: no-transform, must-revalidate, max-age=86400
Vary: Accept-Encoding
Content-Length: 626


Two questions:

1. What is this that is returned? It's an empty context object. Where's it coming from?
2. Related: why did adding an Accept header to the GET request change the Link headers in the response?

Thanks again,

-Mike

Aaron Coburn

unread,
May 8, 2019, 5:53:27 PM5/8/19
to trell...@googlegroups.com
Hi Mike,
This is expected behavior, and what you are seeing relates to how we try negotiate Binaries and their ldp:RDFSource descriptions within the constraints of a HTTP and RDF. Technically, the URL for the description is at /path?ext=description, but it is also possible to access that description directly at the URL of the binary. So, if you try to fetch the resource at the URL of the binary but you request RDF, then Trellis will provide the RDF description. You can also try to fetch text/turtle.

And you will see an empty RDF response because you haven't put anything into that description, but if you had done a sparql-update on the description, then the response would contain triples.

The challenge here has to do with negotiating the semantics of RDF, LDP and HTTP in a way that makes sense for all of these. Effectively, the description "describes" the binary, so the subject of the description should be the binary's URL; however, in a Sparql-Update request, the "<>" form refers to the URL itself, so then you get into a strange issue with the subject now being the *description* (i.e. /path?ext=description) and not the binary. The solution for Trellis is to do a little sleight-of-hand with a description header of `Link: </path#description>; rel="alternate"`, which actually points back to the Binary's URL itself (since fragment URLs are visible only to javascript/client applications).

I actually think that there isn't a really clean solution here; this was my best attempt at trying to appease all the various specifications involved in a semantically coherent way. But you're right, this can be a little confusing in certain contexts.

Cheers, Aaron





--
You received this message because you are subscribed to the Google Groups "Trellis LDP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trellis-ldp...@googlegroups.com.
To post to this group, send email to trell...@googlegroups.com.
Visit this group at https://groups.google.com/group/trellis-ldp.
To view this discussion on the web visit https://groups.google.com/d/msgid/trellis-ldp/843824e6-73b3-4bb1-8676-e17003eef21a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Michael Giarlo

unread,
May 8, 2019, 7:07:09 PM5/8/19
to Trellis LDP
Thank you, Aaron. I now see that this is already well documented as well: https://github.com/trellis-ldp/trellis/wiki/Resource-Management#retrieving-resources

-Mike
To unsubscribe from this group and stop receiving emails from it, send an email to trell...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages