Hm, now I'm not sure whether I can give a good example of managing the JSON-LD HTTP client within Jena. oaj.riot.lang.JsonLDReader doesn't seem to allow users to get at the DocumentLoader instance in use, and that's where the JSON-LD docs show an override to use a specific client. I don't see any static state of the kind you describe in JSON-LD, Stian-- can you give me a pointer?
--- A. Soroka The University of Virginia Library > On Nov 9, 2016, at 11:46 AM, Stian Soiland-Reyes <[email protected]> wrote: > > Yeah, as the client is set static inside JSON-LD Java it might not > good for be Jena HttpOps to be "helpful" and propagate its client - > at least not without a flag. But we can link to it from our > documentation. > > On 9 November 2016 at 16:39, A. Soroka <[email protected]> wrote: >> Hm, that's a really good point. I don't understand what's happening in >> JSON-LD very well, but I think you must be correct to say that it wouldn't >> take up a supplied client, because it wouldn't be using state from Jena. >> I'll check this a bit in the code and add a note as you suggest. >> >> --- >> A. Soroka >> The University of Virginia Library >> >>> On Nov 9, 2016, at 11:37 AM, Stian Soiland-Reyes <[email protected]> wrote: >>> >>> I think the new text looks good, quite easy to understand. >>> >>> Could you add a paragraph about when the configured client would be >>> used? It might not be clear when this HttpClient would be accessed >>> or not. For instance I assume it would be used for remote SPARQL >>> queries or loading of HTTP URLs from RDFDataMgr -- but may not be >>> propagated through to JSON-LD Java's @context loading - which has a >>> similar httpclient setting and documentation on how to configure >>> caching [1] >>> >>> [1] https://github.com/jsonld-java/jsonld-java#controlling-network-traffic >>> >>> >>> >>> >>> On 9 November 2016 at 15:42, A. Soroka <[email protected]> wrote: >>>> Done. I'll wait to hear from other folks before pulling a trigger on >>>> (re)publishing the site. >>>> >>>> --- >>>> A. Soroka >>>> The University of Virginia Library >>>> >>>>> On Nov 9, 2016, at 6:30 AM, Andy Seaborne <[email protected]> wrote: >>>>> >>>>> Great - >>>>> >>>>> One (!) other thing: >>>>> >>>>> A section specifically calling out migrating SPARQL remote calls: >>>>> QueryExecutionFactory.sparqlService and QueryEngineHTTP. >>>>> >>>>> On the latter, older code may still be directly using >>>>> QueryEngineHTTP.setBasicAuthentication >>>>> >>>>> Andy >>>>> >>>>> On 08/11/16 17:58, A. Soroka wrote: >>>>>> I've made those changes-- should be restaging now. >>>>>> >>>>>> --- >>>>>> A. Soroka >>>>>> The University of Virginia Library >>>>>> >>>>>>> On Nov 8, 2016, at 12:40 PM, Andy Seaborne <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 08/11/16 16:59, A. Soroka wrote: >>>>>>>> This commit includes the new docs for HTTP behavior in Jena 3.1.1. I >>>>>>>> can't find any way to see a view of this on the staging site-- >>>>>>>> https://jena.staging.apache.org/ just seems to proxy >>>>>>>> https://cms.apache.org/, for some reason? >>>>>>>> >>>>>>> >>>>>>> It does not for me. >>>>>>> >>>>>>> Try http://jena.staging.apache.org/ (not https) >>>>>>> >>>>>>> PDF attached, cc'ed to you in the hope it get through. >>>>>>> >>>>>>> Comments: >>>>>>> >>>>>>> 1/ I'd put the current (3.1.1) text first and the previous second so >>>>>>> the current is more visible. >>>>>>> >>>>>>> Links at the end of the intro to "current" and "previous", or in the >>>>>>> intro as this difference is mentioned. >>>>>>> >>>>>>> 2/ Title tweaking: >>>>>>> >>>>>>> "HTTP Authentication after Jena 3.1.0" -> >>>>>>> "HTTP Authentication from Jena 3.1.1" >>>>>>> >>>>>>> "HTTP Authentication before Jena 3.1.0" => >>>>>>> "HTTP Authentication from Jena 3.0.0 to 3.1.0" >>>>>>> >>>>>>> (so the range includes 3.1.0 !) >>>>>>> >>>>>>> Mentioning Jena 2.x is not necessary IMO - the additional detail adds >>>>>>> confusion for current users and 3.x upgrading users (the majority). >>>>>>> >>>>>>> 3/ >>>>>>> "Simple authentication using username and password" >>>>>>> >>>>>>> "Authenticating via a form" >>>>>>> >>>>>>> The <h5> don't show up as different on teh screen for me so maybe bump >>>>>>> <h4> "Examples of authentication" up a level to <h3> and move sub <5> >>>>>>> to <h4> . >>>>>>> >>>>>>> Maybe drop <h3> "Applying Authentication" (section title immediately >>>>>>> after a section title) and have the paragraph there straight away. >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>>> --- >>>>>>>> A. Soroka >>>>>>>> The University of Virginia Library >>>>>>>> >>>>>>>>> On Nov 8, 2016, at 11:53 AM, [email protected] wrote: >>>>>>>>> >>>>>>>>> Author: ajs6f >>>>>>>>> Date: Tue Nov 8 16:53:48 2016 >>>>>>>>> New Revision: 1768736 >>>>>>>>> >>>>>>>>> URL: http://svn.apache.org/viewvc?rev=1768736&view=rev >>>>>>>>> Log: >>>>>>>>> Updates for HTTP behavior in Jena 3.1.1 >>>>>>>>> >>>>>>>>> Modified: >>>>>>>>> jena/site/trunk/content/documentation/query/http-auth.mdtext >>>>>>>>> jena/site/trunk/content/documentation/query/service.mdtext >>>>>>>>> >>>>>>>>> Modified: jena/site/trunk/content/documentation/query/http-auth.mdtext >>>>>>>>> URL: >>>>>>>>> http://svn.apache.org/viewvc/jena/site/trunk/content/documentation/query/http-auth.mdtext?rev=1768736&r1=1768735&r2=1768736&view=diff >>>>>>>>> ============================================================================== >>>>>>>>> --- jena/site/trunk/content/documentation/query/http-auth.mdtext >>>>>>>>> (original) >>>>>>>>> +++ jena/site/trunk/content/documentation/query/http-auth.mdtext Tue >>>>>>>>> Nov 8 16:53:48 2016 >>>>>>>>> @@ -16,10 +16,12 @@ Notice: Licensed to the Apache Softwa >>>>>>>>> specific language governing permissions and limitations >>>>>>>>> under the License. >>>>>>>>> >>>>>>>>> -As of ARQ 2.11.0 there is a new unified HTTP operation framework >>>>>>>>> that provides a uniform mechanism for >>>>>>>>> -HTTP authentication that also allows ARQ to support a broader range >>>>>>>>> of authentication mechanisms than were previously possible. >>>>>>>>> +From ARQ 2.11.0 through ARQ 3.1.0 there is a Jena-specific unified >>>>>>>>> HTTP operation framework that provides a uniform mechanism for >>>>>>>>> +HTTP authentication that also allows ARQ to support a broader range >>>>>>>>> of authentication mechanisms than were previously possible. After ARQ >>>>>>>>> 3.1.0, Jena exposes the underlying HTTP Commons functionality to the >>>>>>>>> same end. This documentation is therefore devided into two sections. >>>>>>>>> The first explains the older Jena-specific functionality, and the >>>>>>>>> second explains how to use HTTP Commons code to the same ends. >>>>>>>>> >>>>>>>>> -## Applying Authentication >>>>>>>>> +## HTTP Authentication before ARQ 3.1.0 >>>>>>>>> + >>>>>>>>> +### Applying Authentication >>>>>>>>> >>>>>>>>> APIs that support authentication typically provide two methods for >>>>>>>>> providing authenticators, a `setAuthentication(String username, >>>>>>>>> char[] password)` method >>>>>>>>> which merely configures a `SimpleAuthenticator`. There will also be >>>>>>>>> a `setAuthenticator(HttpAuthenticator authenticator)` method >>>>>>>>> @@ -41,14 +43,14 @@ avoids the needs to cast and manually se >>>>>>>>> ... >>>>>>>>> } >>>>>>>>> >>>>>>>>> -### Authenticators >>>>>>>>> +#### Authenticators >>>>>>>>> >>>>>>>>> Authentication mechanisms are provided by [HttpAuthenticator][1] >>>>>>>>> implementations of which a number are provided built into ARQ. >>>>>>>>> >>>>>>>>> This API provides the authenticator with access to the `HttpClient`, >>>>>>>>> `HttpContext` and target `URI` of the request that is about to be >>>>>>>>> carried >>>>>>>>> out. This allows for authenticators to add credentials to requests >>>>>>>>> on a per-request basis and/or to use different mechanisms and >>>>>>>>> credentials for different services. >>>>>>>>> >>>>>>>>> -#### SimpleAuthenticator >>>>>>>>> +##### SimpleAuthenticator >>>>>>>>> >>>>>>>>> The [simple authenticator][2] is as the name suggests the simplest >>>>>>>>> implementation. It takes a single set of credentials which is >>>>>>>>> applied to >>>>>>>>> any service. >>>>>>>>> @@ -56,7 +58,7 @@ any service. >>>>>>>>> Authentication however is not preemptive so unless the remote service >>>>>>>>> sends a HTTP challenge (401 Unauthorized or 407 Proxy Authorization >>>>>>>>> Required) then credentials will not actually be submitted. >>>>>>>>> >>>>>>>>> -#### ScopedAuthenticator >>>>>>>>> +##### ScopedAuthenticator >>>>>>>>> >>>>>>>>> The [scoped authenticator][3] is an authenticator which maps >>>>>>>>> credentials to different service URIs. This allows you to specify >>>>>>>>> different >>>>>>>>> credentials for different services as appropriate. Similarly to the >>>>>>>>> simple authenticator this is not preemptive authentication so >>>>>>>>> credentials are >>>>>>>>> @@ -67,13 +69,13 @@ if you define credentialsfor `http://exa >>>>>>>>> e.g. `http://example.org/some/path`. However if you had also defined >>>>>>>>> credentials for `http://example.org/some/path` then these would be >>>>>>>>> used in favor of those for `http://example.org` >>>>>>>>> >>>>>>>>> -#### ServiceAuthenticator >>>>>>>>> +##### ServiceAuthenticator >>>>>>>>> >>>>>>>>> The [service authenticator][4] is an authenticator which uses >>>>>>>>> information encoded in the ARQ context and basically provides access >>>>>>>>> to the >>>>>>>>> existing credential provision mechanisms provided for the `SERVICE` >>>>>>>>> clause, see [Basic Federated Query][5] for more information on >>>>>>>>> configuration for this. >>>>>>>>> >>>>>>>>> -#### FormsAuthenticator >>>>>>>>> +##### FormsAuthenticator >>>>>>>>> >>>>>>>>> The [forms authenticator][6] is an authenticator usable with services >>>>>>>>> that require form based logins and use session cookies to verify >>>>>>>>> login state. >>>>>>>>> This is intended for use with services that don't support HTTP's >>>>>>>>> built-in authentication mechanisms for whatever reason. One example >>>>>>>>> of this >>>>>>>>> @@ -104,7 +106,7 @@ that maps each service to an associated >>>>>>>>> >>>>>>>>> Currently forms based login that require more than just a username >>>>>>>>> and password are not supported. >>>>>>>>> >>>>>>>>> -#### PreemptiveBasicAuthenticator >>>>>>>>> +##### PreemptiveBasicAuthenticator >>>>>>>>> >>>>>>>>> This [authenticator][8] is a decorator over another authenticator >>>>>>>>> that enables preemptive basic authentication, this **only** works for >>>>>>>>> servers >>>>>>>>> that support basic authentication and so will cause authentication >>>>>>>>> failures when any other authentication scheme is required. You >>>>>>>>> should **only** >>>>>>>>> @@ -121,20 +123,12 @@ Also be aware that basic authentication >>>>>>>>> many servers will use more secure schemes like Digest authentication >>>>>>>>> which **cannot** be done preemptively as they require more complex >>>>>>>>> challenge response sequences. >>>>>>>>> >>>>>>>>> -#### DelegatingAuthenticator >>>>>>>>> +##### DelegatingAuthenticator >>>>>>>>> >>>>>>>>> The [delegating authenticator][12] allows for mapping different >>>>>>>>> authenticators to different services, this is useful when you need to >>>>>>>>> mix and >>>>>>>>> match the types of authentication needed. >>>>>>>>> >>>>>>>>> -### Debugging Authentication >>>>>>>>> - >>>>>>>>> -ARQ uses [Apache Http Client][14] for all its HTTP operations and >>>>>>>>> this provides detailed logging information that can be used for >>>>>>>>> debugging. To >>>>>>>>> -see this information you need to configure your logging framework to >>>>>>>>> set the `org.apache.http` package to either `DEBUG` or `TRACE` level. >>>>>>>>> - >>>>>>>>> -The `DEBUG` level will give you general diagnostic information about >>>>>>>>> requests and responses while the `TRACE` level will give you detailed >>>>>>>>> -HTTP traces i.e. allow you to see the exact HTTP requests and >>>>>>>>> responses which can be extremely useful for debugging authentication >>>>>>>>> problems. >>>>>>>>> - >>>>>>>>> -### The Default Authenticator >>>>>>>>> +#### The Default Authenticator >>>>>>>>> >>>>>>>>> Since it may not always be possible/practical to configure >>>>>>>>> authenticators on a per-request basis the API includes a means to >>>>>>>>> specify a default >>>>>>>>> authenticator that is used when no authenticator is explicitly >>>>>>>>> specified. This may be configured via the >>>>>>>>> @@ -148,6 +142,82 @@ provided that it is using ARQs APIs to m >>>>>>>>> >>>>>>>>> Note that the default authenticator may be disabled by setting it to >>>>>>>>> `null`. >>>>>>>>> >>>>>>>>> +## HTTP Authentication after ARQ 3.1.0 >>>>>>>>> + >>>>>>>>> +### Applying Authentication >>>>>>>>> + >>>>>>>>> +APIs that support authentication typically provide methods for >>>>>>>>> providing an [HttpClient] for use with the given instance of that API >>>>>>>>> class. `HttpClient` is [extremely flexible][16] and can handle most >>>>>>>>> scenarios very well. Since it may not always be possible/practical to >>>>>>>>> configure authenticators on a per-request basis the API includes a >>>>>>>>> means to specify a default client that is used when no other client >>>>>>>>> is explicitly specified. This may be configured via the >>>>>>>>> +`setDefaultHttpClient(HttpClient httpClient)` method of the >>>>>>>>> [HttpOp][13] class. This allows for static-scoped configuration of >>>>>>>>> HTTP behavior. >>>>>>>>> + >>>>>>>>> +#### Examples of authentication >>>>>>>>> + >>>>>>>>> +This section includes a series of examples showing how to use HTTP >>>>>>>>> Commons classes to perform authenticated work. Most of them take >>>>>>>>> advantage of `HttpOp.setDefaultHttpClient` as described above. >>>>>>>>> + >>>>>>>>> +##### Simple authentication using username and password >>>>>>>>> + >>>>>>>>> +First we build an authenticating client: >>>>>>>>> + >>>>>>>>> + CredentialsProvider credsProvider = new >>>>>>>>> BasicCredentialsProvider(); >>>>>>>>> + Credentials credentials = new >>>>>>>>> UsernamePasswordCredentials("user", "passwd"); >>>>>>>>> + credsProvider.setCredentials(AuthScope.ANY, credentials); >>>>>>>>> + HttpClient httpclient = HttpClients.custom() >>>>>>>>> + .setDefaultCredentialsProvider(credsProvider) >>>>>>>>> + .build(); >>>>>>>>> + HttpOp.setDefaultHttpClient(httpclient); >>>>>>>>> + >>>>>>>>> +Notice that we gave no scope for use with the credentials >>>>>>>>> (`AuthScope.ANY`). We can make further use of that parameter if we >>>>>>>>> want to assign a scope for some credentials: >>>>>>>>> + >>>>>>>>> + CredentialsProvider credsProvider = new >>>>>>>>> BasicCredentialsProvider(); >>>>>>>>> + Credentials unscopedCredentials = new >>>>>>>>> UsernamePasswordCredentials("user", "passwd"); >>>>>>>>> + credsProvider.setCredentials(AuthScope.ANY, unscopedCredentials); >>>>>>>>> + Credentials scopedCredentials = new >>>>>>>>> UsernamePasswordCredentials("user", "passwd"); >>>>>>>>> + final String host = "http://example.com/sparql";; >>>>>>>>> + final int port = 80; >>>>>>>>> + final String realm = "aRealm"; >>>>>>>>> + final String schemeName = "DIGEST"; >>>>>>>>> + AuthScope authscope = new AuthScope(host, port, realm, >>>>>>>>> schemeName); >>>>>>>>> + credsProvider.setCredentials(authscope, scopedCredentials); >>>>>>>>> + HttpClient httpclient = HttpClients.custom() >>>>>>>>> + .setDefaultCredentialsProvider(credsProvider) >>>>>>>>> + .build(); >>>>>>>>> + HttpOp.setDefaultHttpClient(httpclient); >>>>>>>>> + >>>>>>>>> +##### Authenticating via a form >>>>>>>>> + >>>>>>>>> +For this case we introduce an [HttpClientContext][17], which we can >>>>>>>>> use to retrieve the cookie we get from logging into a form. We then >>>>>>>>> use the cookie to authenticate elsewhere. >>>>>>>>> + >>>>>>>>> + // we'll use this context to maintain our HTTP "conversation" >>>>>>>>> + HttpClientContext httpContext = new HttpClientContext(); >>>>>>>>> + >>>>>>>>> + // first we use a method on HttpOp to log in and get our cookie >>>>>>>>> + Params params = new Params(); >>>>>>>>> + params.addParam("username", "Bob Wu"); >>>>>>>>> + params.addParam("password", "my password"); >>>>>>>>> + HttpOp.execHttpPostForm("http://example.com/loginform";, params , >>>>>>>>> null, null, null, httpContext); >>>>>>>>> + >>>>>>>>> + // now our cookie is stored in httpContext >>>>>>>>> + CookieStore cookieStore = httpContext.getCookieStore(); >>>>>>>>> + >>>>>>>>> + // lastly we build a client that uses that cookie >>>>>>>>> + HttpClient httpclient = HttpClients.custom() >>>>>>>>> + .setDefaultCookieStore(cookieStore) >>>>>>>>> + .build(); >>>>>>>>> + HttpOp.setDefaultHttpClient(httpclient); >>>>>>>>> + >>>>>>>>> +## Other concerns >>>>>>>>> + >>>>>>>>> +### Debugging Authentication >>>>>>>>> + >>>>>>>>> +ARQ uses [Apache Http Client][14] for all its HTTP operations and >>>>>>>>> this provides detailed logging information that can be used for >>>>>>>>> debugging. To >>>>>>>>> +see this information you need to configure your logging framework to >>>>>>>>> set the `org.apache.http` package to either `DEBUG` or `TRACE` level. >>>>>>>>> + >>>>>>>>> +The `DEBUG` level will give you general diagnostic information about >>>>>>>>> requests and responses while the `TRACE` level will give you detailed >>>>>>>>> +HTTP traces i.e. allow you to see the exact HTTP requests and >>>>>>>>> responses which can be extremely useful for debugging authentication >>>>>>>>> problems. >>>>>>>>> + >>>>>>>>> +### Authenticating to a SPARQL federated service >>>>>>>>> + >>>>>>>>> +ARQ allows the user to configure HTTP behavior to use on a >>>>>>>>> per-`SERVICE` basis, including authentication behavior such as is >>>>>>>>> described above. This works via the ARQ context. See [Basic Federated >>>>>>>>> Query][5] for more information on configuring this functionality. >>>>>>>>> + >>>>>>>>> [1]: >>>>>>>>> http://jena.apache.org/documentation/javadoc/arq/org/apache/jena/atlas/web/auth/HttpAuthenticator.html >>>>>>>>> [2]: >>>>>>>>> http://jena.apache.org/documentation/javadoc/arq/org/apache/jena/atlas/web/auth/SimpleAuthenticator.html >>>>>>>>> [3]: >>>>>>>>> http://jena.apache.org/documentation/javadoc/arq/org/apache/jena/atlas/web/auth/ScopedAuthenticator.html >>>>>>>>> @@ -161,4 +231,7 @@ Note that the default authenticator may >>>>>>>>> [11]: >>>>>>>>> http://jena.apache.org/documentation/javadoc/arq/org/apache/jena/web/DatasetGraphAccessorHTTP.html >>>>>>>>> [12]: >>>>>>>>> http://jena.apache.org/documentation/javadoc/arq/org/apache/jena/atlas/web/auth/DelegatingAuthenticator.html >>>>>>>>> [13]: >>>>>>>>> http://jena.apache.org/documentation/javadoc/arq/org/apache/jena/riot/web/HttpOp.html >>>>>>>>> - [14]: http://hc.apache.org >>>>>>>>> \ No newline at end of file >>>>>>>>> + [14]: http://hc.apache.org >>>>>>>>> + [15]: >>>>>>>>> https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/HttpClient.html >>>>>>>>> + [16]: https://hc.apache.org/httpcomponents-client-ga/examples.html >>>>>>>>> + [17]: >>>>>>>>> https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/protocol/HttpClientContext.html >>>>>>>>> \ No newline at end of file >>>>>>>>> >>>>>>>>> Modified: jena/site/trunk/content/documentation/query/service.mdtext >>>>>>>>> URL: >>>>>>>>> http://svn.apache.org/viewvc/jena/site/trunk/content/documentation/query/service.mdtext?rev=1768736&r1=1768735&r2=1768736&view=diff >>>>>>>>> ============================================================================== >>>>>>>>> --- jena/site/trunk/content/documentation/query/service.mdtext >>>>>>>>> (original) >>>>>>>>> +++ jena/site/trunk/content/documentation/query/service.mdtext Tue >>>>>>>>> Nov 8 16:53:48 2016 >>>>>>>>> @@ -48,19 +48,18 @@ distributed query evaluation. The algebr >>>>>>>>> without regard to how selective the pattern is. So the order of the >>>>>>>>> query will affect the speed of execution. Because it involves HTTP >>>>>>>>> operations, asking the query in the right order matters a lot. >>>>>>>>> -Don't ask for the whole of a bookstore just to find book whose >>>>>>>>> +Don't ask for the whole of a bookstore just to find a book whose >>>>>>>>> title comes from a local RDF file - ask the bookshop a query with >>>>>>>>> the title already bound from earlier in the query. >>>>>>>>> >>>>>>>>> ## Controlling `SERVICE` requests. >>>>>>>>> >>>>>>>>> -The `SERVICE` operation in a SPARQL query may be configured via the >>>>>>>>> Context. >>>>>>>>> -The values for configuration can be set in the global context >>>>>>>>> (accessed via >>>>>>>>> +The `SERVICE` operation in a SPARQL query may be configured via the >>>>>>>>> Context. The values for configuration can be set in the global >>>>>>>>> context (accessed via >>>>>>>>> `ARQ.getContext()`) or in the per-query execution context. >>>>>>>>> >>>>>>>>> The prefix `srv:` is the IRI `<http://jena.hpl.hp.com/Service#>`. >>>>>>>>> >>>>>>>>> -### Summary >>>>>>>>> +### Configuration for ARQ through version 3.1.0 >>>>>>>>> >>>>>>>>> Symbol | Usage >>>>>>>>> ------ | ----- >>>>>>>>> @@ -71,7 +70,7 @@ Symbol | Usage >>>>>>>>> `srv:queryAuthPwd` | Basic authentication >>>>>>>>> `srv:queryContext` | Per-endpoint configuration >>>>>>>>> >>>>>>>>> -### `srv:queryTimeout` >>>>>>>>> +#### `srv:queryTimeout` >>>>>>>>> >>>>>>>>> Set the connect and read timeouts for the query. >>>>>>>>> >>>>>>>>> @@ -86,21 +85,21 @@ read timout = 0 >>>>>>>>> >>>>>>>>> Values of 0 indicate no timeout and service operation will wait until >>>>>>>>> the remote server responds. >>>>>>>>> >>>>>>>>> -### `srv:queryGzip` >>>>>>>>> +#### `srv:queryGzip` >>>>>>>>> >>>>>>>>> Sets the allow Gzip flag. >>>>>>>>> >>>>>>>>> Boolean: True indicates that gzip compressed data is acceptable. >>>>>>>>> false >>>>>>>>> >>>>>>>>> -### `srv:queryDeflate` >>>>>>>>> +#### `srv:queryDeflate` >>>>>>>>> >>>>>>>>> Sets the allow Deflate flag. >>>>>>>>> >>>>>>>>> Boolean: True indicates that deflate compression is acceptable >>>>>>>>> False >>>>>>>>> >>>>>>>>> -### `srv:queryAuthUser` >>>>>>>>> +#### `srv:queryAuthUser` >>>>>>>>> >>>>>>>>> Sets the user id for basic auth. >>>>>>>>> >>>>>>>>> @@ -108,7 +107,7 @@ String: The user id to log in with >>>>>>>>> >>>>>>>>> If null or null length no user id is sent. >>>>>>>>> >>>>>>>>> -### `srv:queryAuthPwd` >>>>>>>>> +#### `srv:queryAuthPwd` >>>>>>>>> >>>>>>>>> Sets the password for basic auth. >>>>>>>>> >>>>>>>>> @@ -116,13 +115,43 @@ String: The password to log in with. >>>>>>>>> >>>>>>>>> If null or null length no password is sent. >>>>>>>>> >>>>>>>>> -### srv:serviceContext >>>>>>>>> +#### `srv:serviceContext` >>>>>>>>> Provides a mechanism to override system context settings on a per URI >>>>>>>>> basis. >>>>>>>>> >>>>>>>>> The value is a `Map<String,Context>` where the map key is the URI of >>>>>>>>> the service endpoint, and the `Context` is a set of values to >>>>>>>>> override the default values. >>>>>>>>> >>>>>>>>> If a context is provided for the URI the system context is copied and >>>>>>>>> the URI specific values are then copied in. This ensures that any >>>>>>>>> URI specific settings will be used. >>>>>>>>> >>>>>>>>> +### Configuration for ARQ after version 3.1.0 >>>>>>>>> >>>>>>>>> +Symbol | Usage | Default >>>>>>>>> +------ | ----- | ------- >>>>>>>>> +`srv:queryTimeout` | Set timeouts | none >>>>>>>>> +`srv:queryCompression` | Enable use of deflation and GZip | true >>>>>>>>> +`srv:queryClient` | Enable use of a specific client | none >>>>>>>>> +`srv:queryContext` | Per-endpoint configuration | none >>>>>>>>> + >>>>>>>>> +#### `srv:queryTimeout` >>>>>>>>> + >>>>>>>>> +As documented above. >>>>>>>>> + >>>>>>>>> + >>>>>>>>> +#### `srv:queryCompression` >>>>>>>>> + >>>>>>>>> +Sets the flag for use of deflation and GZip. >>>>>>>>> + >>>>>>>>> +Boolean: True indicates that gzip compressed data is acceptable. >>>>>>>>> + >>>>>>>>> +#### `srv:queryClient` >>>>>>>>> + >>>>>>>>> +Enable use of a specific client >>>>>>>>> + >>>>>>>>> +Provides a slot for a specific [HttpClient][1] for use with a >>>>>>>>> specific `SERVICE` >>>>>>>>> + >>>>>>>>> +#### `srv:serviceContext` >>>>>>>>> + >>>>>>>>> +As documented above. >>>>>>>>> >>>>>>>>> [ARQ documentation index](index.html) >>>>>>>>> + >>>>>>>>> +[1]: >>>>>>>>> https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/HttpClient.html >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >>> >>> >>> -- >>> Stian Soiland-Reyes >>> http://orcid.org/0000-0001-9842-9718 >> > > > > -- > Stian Soiland-Reyes > http://orcid.org/0000-0001-9842-9718
