You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Andy Seaborne (JIRA)" <ji...@apache.org> on 2017/07/28 13:50:01 UTC

[jira] [Resolved] (JENA-1378) RDFDataMgr does not perform conneg when reading remote RDF resources

     [ https://issues.apache.org/jira/browse/JENA-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Seaborne resolved JENA-1378.
---------------------------------
       Resolution: Fixed
         Assignee: Andy Seaborne
    Fix Version/s: Jena 3.5.0

> RDFDataMgr does not perform conneg when reading remote RDF resources
> --------------------------------------------------------------------
>
>                 Key: JENA-1378
>                 URL: https://issues.apache.org/jira/browse/JENA-1378
>             Project: Apache Jena
>          Issue Type: Bug
>          Components: ARQ
>    Affects Versions: Jena 3.4.0
>            Reporter: Aaron Coburn
>            Assignee: Andy Seaborne
>             Fix For: Jena 3.5.0
>
>
> In the past, I have been able to use RDFDataMgr.read(Graph, String) to fetch vocabularies like so:
> final Graph graph = Factory.createDefaultGraph();
> RDFDataMgr.read(graph, "http://purl.org/dc/terms");
> This no longer works in 3.4.0. The error is:
>      org.apache.jena.riot.RiotException: Failed to determine the content type: (URI=http://purl.org/dc/terms/ : stream=text/html)
> The key thing about these remote resources is that they involve content negotiation in order to get to the RDF serialization; otherwise an HTML page is returned that cannot be parsed by RIOT.
> Adding a Lang attribute to the read() function does not help.
> This appears to be due to the RDFParser library not including an Accept header in the HTTP request to the remote resource: https://git.io/v7sTV
> Perhaps a good solution would be to provide a default accept header ("text/turtle, application/rdf+xml, application/ld+json") or, even better, that accept header could be configurable by a client.
> A work-around for me is to just use the HttpOp.execHttpGet function directly, but it would be nice if this functioned as it once did.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)