[jira] [Created] (JENA-480) Unify HTTP usage and authentication mechanisms in ARQ

["Rob Vesse (JIRA)" <ji...@apache.org>]

Rob Vesse created JENA-480:
------------------------------

             Summary: Unify HTTP usage and authentication mechanisms in ARQ
                 Key: JENA-480
                 URL: https://issues.apache.org/jira/browse/JENA-480
             Project: Apache Jena
          Issue Type: Improvement
          Components: ARQ
            Reporter: Rob Vesse
            Assignee: Rob Vesse
             Fix For: Jena 2.10.2


Currently ARQ uses a mixture of HttpClient and HttpURLConnection to perform various HTTP operations e.g. SPARQL Queries, SPARQL Updates and SPARQL Graph Store Protocol.

This has the effect of making the code somewhat awkward to maintain and makes certain operations like authentication more complex than they need to be because different parts of the system support different modes of authentication.

For example currently SPARQL queries only support Basic Auth and they always pre-authenticate so they cannot do proxy auth or use any other kind of auth method.  On the other hand SPARQL updates use HttpClient which is capable of performing Basic, Digest, NTLM, SPNEGO and Kerberos for both normal and proxy auth but is never pre-authenticates.

This task proposes unifying all HTTP operations in ARQ to use Apache HttpClient since it is more flexible and introducing a more extensible framework for doing authentication.

In terms of HTTP unification we need to convert the following:
- HttpQuery should use HttpClient
- LocatorURL should use HttpClient

In terms of HTTP Authentication my idea is as follows, introduce a new interface HttpAuthenticator which provides an apply(AbstractHttpClient client, URI target) method.  All systems that may permit HTTP auth will allow use of an authenticator, providing a generic interface for authenticators will allow us to introduce authenticators for other auth schemes e.g. form based logins.

We can also provide authenticators that leverage existing mechanisms e.g. storing credentials in a service context which would be used by default.  Existing methods that accept username and password would use simpler authenticators.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira