[
https://issues.apache.org/jira/browse/JENA-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16104977#comment-16104977
]
ASF GitHub Bot commented on JENA-1378:
--------------------------------------
Github user afs commented on a diff in the pull request:
https://github.com/apache/jena/pull/271#discussion_r130092145
--- Diff: jena-arq/src/main/java/org/apache/jena/riot/RDFParserBuilder.java
---
@@ -504,8 +504,10 @@ private HttpClient buildHttpClient() {
Header header = new BasicHeader(k, v);
hdrs.add(header);
});
- HttpClient hc =
CachingHttpClientBuilder.create().setDefaultHeaders(hdrs).build();
- return hc;
+ HttpClient hc = HttpOp.createPoolingHttpClientBuilder()
--- End diff --
A possibility though I like that HttpOp is neutral as to its usage - it is
not RDF-specific and the default headers are none. There are different headers
for graph, datasets and result sets. Responsibility for the customization is in
the RDFParser which here (this is the case of the app making detailed settings)
captures those choices for a reusable parser process.
Adding to the complexity of HttpOp.createPoolingHttpClient seems a slippery
slope that goes against the builder pattern (IMO). It would be easier if there
were an HttpComponents way to say "make a builder that would produce this
HttpClient" capturing the internal settings details of an HttpClient.
> 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
>
> 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)
