You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Bardo Nelgen <ma...@bnnperformances.de> on 2019/02/10 17:56:55 UTC

Fuseki remote TLS load

Hi all,

is there a way to determine which types of TLS connection Fuseki can use 
to load remote resources provided via a SPARQL "LOAD" directive ?

We recently updated our development servers to match a more contemporary 
TLS cipher set and since then have encountered permanent connection errors.

Suggestions welcome !!

— Bardo


Re: Fuseki remote TLS load

Posted by Andy Seaborne <an...@apache.org>.


On 10/02/2019 21:15, ajs6f wrote:
> Andy, does that go by the usual code paths in ARQ?

Yes, it does RDFDataMgr.open(...).

QueryEngineWorker, line 150-ish.

> 
> If the answer to the above question is yes, then it's an Apache Commons HTTP client that is the underlying machine here. You can adjust it with methods in Jena's class HttpOp in jena-arq.

> 
> ajs6f
> 
>> On Feb 10, 2019, at 12:56 PM, Bardo Nelgen <ma...@bnnperformances.de> wrote:
>>
>>
>> Hi all,
>>
>> is there a way to determine which types of TLS connection Fuseki can use to load remote resources provided via a SPARQL "LOAD" directive ?
>>
>> We recently updated our development servers to match a more contemporary TLS cipher set and since then have encountered permanent connection errors.

Which version of Fuseki?

     Andy

>>
>> Suggestions welcome !!
>>
>> — Bardo
>>
> 

Re: Fuseki remote TLS load

Posted by ajs6f <aj...@apache.org>.
Andy, does that go by the usual code paths in ARQ?

If the answer to the above question is yes, then it's an Apache Commons HTTP client that is the underlying machine here. You can adjust it with methods in Jena's class HttpOp in jena-arq.

ajs6f

> On Feb 10, 2019, at 12:56 PM, Bardo Nelgen <ma...@bnnperformances.de> wrote:
> 
> 
> Hi all,
> 
> is there a way to determine which types of TLS connection Fuseki can use to load remote resources provided via a SPARQL "LOAD" directive ?
> 
> We recently updated our development servers to match a more contemporary TLS cipher set and since then have encountered permanent connection errors.
> 
> Suggestions welcome !!
> 
> — Bardo
>