Table of Contents |
---|
Authentication
Basic Authentication
Code Block | ||||
---|---|---|---|---|
| ||||
<conduit name="{http://example.com/}HelloWorldServicePort.http-conduit"
xmlns:sec="http://cxf.apache.org/configuration/security"
xmlns="http://cxf.apache.org/transports/http/configuration">
<authorization>
<sec:UserName>myuser</sec:UserName>
<sec:Password>mypasswd</sec:Password>
<sec:AuthorizationType>Basic</sec:AuthorizationType>
</authorization>
</conduit>
|
...
The file should contain:
Code Block |
---|
CXFClient {
com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true;
};
|
...
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
...
<conduit name="{http://example.com/}HelloWorldServicePort.http-conduit"
xmlns="http://cxf.apache.org/transports/http/configuration">
<authorization>
<AuthorizationType>Negotiate</AuthorizationType>
<Authorization>CXFClient</Authorization>
</authorization>
</conduit>
...
|
...
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
...
<jaxws:client>
<jaxws:properties>
<entry key="auth.spnego.useKerberosOid" value="true"/>
</jaxws:properties>
</jaxws:client>
...
|
...
This can be done before a client invocation is made, by setting a client request context property, or by extending 'org.apache.cxf.transport.http.auth.AbstractSpnegoAuthSupplier'.
NTLM Authentication
CXF doesn't support NTLM authentication "out of the box" on Java 5, but with some additional libraries and configuration, the standard HttpURLConnection objects that we use can do the NTLM authentication. On Java 6, NTLM authentication is built into the Java runtime and you don't need to do anything special.
On Java 5, you need a library that will augment the HttpURLConnection to do it. See: http://jcifs.samba.org/src/docs/httpclient.html Note: jcifs is LGPL licensed, not Apache licensed.
Next, you need to configure jcifs to use the correct domains, wins servers, etc... Notice that the
bit which sets the username/password to use for NTLM is commented out. If credentials are
missing jcifs will use the underlying NT credentials.
Please see this thread for more information on the latter option.
Note in the case of reusing the existing credential, the policy configuration does not need to reference a login module name:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
...
<conduit name="{http://example.com/}HelloWorldServicePort.http-conduit"
xmlns="http://cxf.apache.org/transports/http/configuration">
<authorization>
<AuthorizationType>Negotiate</AuthorizationType>
</authorization>
</conduit>
...
|
NTLM Authentication
CXF doesn't support NTLM authentication "out of the box" on Java 5, but with some additional libraries and configuration, the standard HttpURLConnection objects that we use can do the NTLM authentication. On Java 6, NTLM authentication is built into the Java runtime and you don't need to do anything special.
On Java 5, you need a library that will augment the HttpURLConnection to do it. See: http://jcifs.samba.org/src/docs/httpclient.html Note: jcifs is LGPL licensed, not Apache licensed.
Next, you need to configure jcifs to use the correct domains, wins servers, etc... Notice that the
bit which sets the username/password to use for NTLM is commented out. If credentials are
missing jcifs will use the underlying NT credentials.
Code Block | ||||
---|---|---|---|---|
| ||||
//Set the jcifs properties | ||||
Code Block | ||||
java | java | //Set the jcifs properties jcifs.Config.setProperty("jcifs.smb.client.domain", "ben.com"); jcifs.Config.setProperty("jcifs.netbios.smb.client.domain", "ben.com"); jcifs.Config.setProperty("jcifs.netbios.wins", "xxx.xxx.xxx.xxx"); jcifs.Config.setProperty("jcifs.smb.client.soTimeout", "300000"); // 5 minutes jcifs.Config.setProperty("jcifs.netbios.cachePolicy", "1200"); // 20 minutes //jcifs.Config.setProperty("jcifs.smb.client.username", "myNTLogin"); //jcifs.Config.setProperty("jcifs.smb.client.password", "secret"); //Register the jcifs URL handler to enable NTLM jcifs.Config.registerSmbURLHandler(); |
Finally, you need to setup the CXF client to turn off chunking. The reason is that the NTLM authentication requires a 3 part handshake which breaks the streaming.
Code Block |
---|
//Turn off chunking so that NTLM can occur
Client client = ClientProxy.getClient(port);
HTTPConduit http = (HTTPConduit) client.getConduit();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setConnectionTimeout(36000);
httpClientPolicy.setAllowChunking(false);
http.setClient(httpClientPolicy);
|
Configuring SSL Support
When using an "https" URL, CXF will, by default, use the certs and keystores that are part of the JDK. For many HTTPs applications, that is enough and no configuration is necessary. However, when using custom client certificates or self signed server certificates or similar, you may need to specifically configure in the keystores and trust managers and such to establish the SSL connection.
Please also see Asynchronous HTTP Conduit for more information on NTLM.
Proxy Authentication
Proxy authentication can be configured as follows.
Code Block |
---|
<conduit name="{http://example.com/}HelloWorldServicePort.http-conduit"
xmlns:sec="http://cxf.apache.org/configuration/security"
xmlns="http://cxf.apache.org/transports/http/configuration">
<proxyAuthorization>
<sec:UserName>myuser</sec:UserName>
<sec:Password>mypasswd</sec:Password>
</proxyAuthorization>
<client AllowChunking="false" ProxyServer="localhost" ProxyServerPort="8080" />
</conduit> |
This works over HTTPS and HTTPS, but note for the latter it is necessary to set the following system property (see here for more information "Disable Basic authentication for HTTPS tunneling"):
Code Block |
---|
-Djdk.http.auth.tunneling.disabledSchemes= |
Configuring SSL Support
When using an "https" URL, CXF will, by default, use the certs and keystores that are part of the JDK. For many HTTPs applications, that is enough and no configuration is necessary. However, when using custom client certificates or self signed server certificates or similar, you may need to specifically configure in the keystores and trust managers and such to establish the SSL connection.
To configure your client to use SSL, you'll need to add an <http:conduit> definition to your XML configuration file. See the Configuration guide to learn how to To configure your client to use SSL, you'll need to add an <http:conduit> definition to your XML configuration file. See the Configuration guide to learn how to supply your own XML configuration file to CXF. If you are already using Spring, this can be added to your existing beans definitions.
A wsdl_first_https sample can be found in the CXF distribution with more detail. Also see this blog entry for another example.
Here is a sample of what your conduit definition might look like:
Code Block | ||||
---|---|---|---|---|
| ||||
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sec="http://cxf.apache.org/configuration/security" xmlns:http="http://cxf.apache.org/transports/http/configuration" xmlns:jaxws="http://java.sun.com/xml/ns/jaxws" xsi:schemaLocation=" http://cxf.apache.org/configuration/security http://cxf.apache.org/schemas/configuration/security.xsd http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> <http:conduit name="{http://apache.org/hello_world}HelloWorld.http-conduit"> <http:tlsClientParameters> <sec:keyManagers keyPassword="password"> <sec:keyStore type="JKS" password="password" file="my/file/dir/Morpit.jks"/> </sec:keyManagers> <sec:trustManagers> <sec:keyStore type="JKS" password="password" file="my/file/dir/Truststore.jks"/> </sec:trustManagers> <sec:cipherSuitesFilter> <!-- these filters ensure that a ciphersuite with export-suitable or null encryption is used, but exclude anonymous Diffie-Hellman key change as this is vulnerable to man-in-the-middle attacks --> <sec:include>.*_EXPORT_.*</sec:include> <sec:include>.*_EXPORT1024_.*</sec:include> <sec:include>.*_WITH_DES_.*</sec:include> <sec:include>.*_WITH_AES_.*</sec:include> <sec:include>.*_WITH_NULL_.*</sec:include> <sec:exclude>.*_DH_anon_.*</sec:exclude> </sec:cipherSuitesFilter> </http:tlsClientParameters> <http:authorization> <sec:UserName>Betty</sec:UserName> <sec:Password>password</sec:Password> </http:authorization> <http:client AutoRedirect="true" Connection="Keep-Alive"/> </http:conduit> </beans> |
The first thing to notice is the "name" attribute on <http:conduit>. This allows CXF to associate this HTTP Conduit configuration with a particular WSDL Port. The name includes the service's namespace, the WSDL port name (as found in the wsdl:service section of the WSDL), and ".http-conduit". It follows this template: "{WSDL Namespace}portName.http-conduit". Note: it's the PORT name, not the service name. Thus, it's likely something like "MyServicePort", not "MyService". If you are having trouble getting the template to work, another (temporary) option for the name value is simply "*.http-conduit".
Another option for the name attribute is a reg-ex expression (e.g., "http://localhost:*") for the ORIGINAL URL of the endpoint. The configuration is matched at conduit creation so the address used in the WSDL or used for the JAX-WS Service.create(...) call can be used for the name. For example, you can do:
Code Block | ||||
---|---|---|---|---|
| ||||
<http:conduit name="http://localhost:8080/.*">
......
</http:conduit>
|
...
If your service endpoint uses an SSL WSDL location (i.e., "https://xxx?wsdl"), you can configure the http conduit to pick up the SSL configuration by using a hardcoded http conduit name of "{http://cxf.apache.org/}TransportURIResolver.http-conduit". The specific HTTP conduit name or a reg-ex expression can still be used.
Advanced Configuration
Keystores (as identified by the sec:keyStore element above) can be identified via any one of three ways: via a file, resource, or url attribute. File locations are either an absolute path or relative to the working directory, the resource attribute is relative to the classpath, and URLs must be a valid URL such as "http://..." "file:///...", etc. Only one attribute of "url", "file", or "resource" is allowed.
Advanced Configuration
HTTP client endpoints can specify a number of HTTP connection attributes including whether the endpoint automatically accepts redirect responses, whether the endpoint can use chunking, whether the endpoint will request a keep-alive, and how the endpoint interacts with proxiesHTTP client endpoints can specify a number of HTTP connection attributes including whether the endpoint automatically accepts redirect responses, whether the endpoint can use chunking, whether the endpoint will request a keep-alive, and how the endpoint interacts with proxies.
A client endpoint can be configured using three mechanisms:
...
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<beans ... xmlns:http-conf="http://cxf.apache.org/transports/http/configuration ... xsi:schemaLocation="... http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd ..."> |
The conduit
element
You configure an HTTP client using the http-conf:conduit
element and its children. The http-conf:conduit
element takes a single attribute, name
, that specifies the WSDL port element that corresponds to the endpoint. The value for the name
attribute takes the form portQName.http-conduit
. For example, the code below shows the http-conf:conduit
element that would be used to add configuration for an endpoint that was specified by the WSDL fragment <port binding="widgetSOAPBinding" name="widgetSOAPPort>
if the endpoint's target namespace was http://widgets.widgetvendor.net
. Alternatively, the name
attribute can be a regular expression to match a URL. This allows configuration of conduits that are not used for purposes of WSDL based endpoints such as JAX-RS and for WSDL retrieval.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
...
<http-conf:conduit name="{http://widgets/widgetvendor.net}widgetSOAPPort.http-conduit">
...
</http-conf:conduit>
<http-conf:conduit name="*.http-conduit">
<!-- you can also using the wild card to specify
the http-conduit that you want to configure -->
...
</http-conf:conduit>
<http-conf:conduit name="http://localhost:8080/.*">
<!-- you can also using the reg-ex URL matching for
the http-conduit that you want to configure -->
...
</http-conf:conduit>
...
|
The http-conf:conduit
element has a number of child elements that specify configuration information. They are described below. See also Sun's JSSE Guide for more information on configuring SSL.
Element | Description |
---|---|
| Specifies the HTTP connection properties such as timeouts, keep-alive requests, content types, etc. |
| Specifies the the parameters for configuring the basic authentication method that the endpoint uses preemptively. |
| Specifies the parameters for configuring basic authentication against outgoing HTTP proxy servers. |
| Specifies the parameters used to configure SSL/TLS. |
|
| Specifies the bean reference or class name of the object that supplies |
the |
authentication information used by the endpoint both preemptively or in response to a 401 HTTP challenge. | |
| Specifies the bean reference or class name of the object that checks the HTTP(S) URLConnection object in order to establish trust for a connection with an HTTPS service provider before any information is transmitted. |
The client
element
The http-conf:client
element is used to configure the non-security properties of a client's HTTP connection. Its attributes, described below, specify the connection's properties.
Attribute | Description |
---|---|
| Specifies the amount of time, in milliseconds, that the client will attempt to establish a connection before it times out. The default is 30000 (30 seconds). |
| Specifies the amount of time, in milliseconds, that the client will wait for a response before it times out. The default is 60000. |
| Specifies if the client will automatically follow a server issued redirection. The default is false. |
| Specifies the maximum number of times a client will retransmit a request to satisfy a redirect. The default is -1 which specifies that unlimited retransmissions are allowed. |
| Specifies whether the client will send requests using chunking. The default is true which specifies that the client will use chunking when sending requests. |
if either of the following are true:
| |
| Specifies the threshold at which CXF will switch from non-chunking to chunking. By default, messages less than 4K are buffered and sent non-chunked. Once this threshold is reached, the message is chunked. |
| Specifies what media types the client is prepared to handle. The value is used as the value of the HTTP |
| Specifies what language (for example, American English) the client prefers for the purposes of receiving a response. The value is used as the value of the HTTP AcceptLanguage property. |
| Specifies what content encodings the client is prepared to handle. Content encoding labels are regulated by the Internet Assigned Numbers Authority (IANA). The value is used as the value of the HTTP |
| Specifies the media type of the data being sent in the body of a message. Media types are specified using multipurpose internet mail extensions (MIME) types. The value is used as the value of the HTTP |
| Specifies the Internet host and port number of the resource on which the request is being invoked. The value is used as the value of the HTTP |
| Specifies whether a particular connection is to be kept open or closed after each request/response dialog. There are two valid values:
|
| Specifies directives about the behavior that must be adhered to by caches involved in the chain comprising a request from a client to a server. |
| Specifies a static cookie to be sent with all requests. |
| Specifies information about the browser from which the request originates. In the HTTP specification from the World Wide Web consortium (W3C) this is also known as the user-agent. Some servers optimize based upon the client that is sending the request. |
| Specifies the URL of the resource that directed the consumer to make requests on a particular service. The value is used as the value of the HTTP Referer property. |
| Specifies the URL of a decoupled endpoint for the receipt of responses over a separate server->client connection. |
| Specifies the URL of the proxy server through which requests are routed. |
| Specifies the port number of the proxy server through which requests are routed. |
NonProxyHosts | Specifies a list of hosts that should be directly routed. This value is a list of patterns separated by '|', where each pattern may start or end with a '*' for wildcard matching. |
| Specifies the type of proxy server used to route requests. Valid values are:
|
Example using the Client
Element
...
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"
xsi:schemaLocation="http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<http-conf:conduit name="{http://apache.org/hello_world_soap_http}SoapPort.http-conduit">
<http-conf:client Connection="Keep-Alive"
MaxRetransmits="1"
AllowChunking="false" />
</http-conf:conduit>
</beans>
|
...
The tlsClientParameters
element
The TLSClientParameters are listed here and here.
Attribute | Default | Since | Description |
---|---|---|---|
|
|
| Certificate Constraints specification. |
| default sslContext cipher suites |
| CipherSuites that will be supported. |
|
|
| filters of the supported CipherSuites that will be supported and used if available. |
| | 2.0.5 | Indicates whether that the hostname given in the HTTPS URL will be checked against the service's Common Name (CN) given in its certificate during SOAP client requests, and failing if there is a mismatch. If set to |
| default JVM provider associated with protocol |
| JSSE provider name. |
| JVM default Key Managers |
| Key Managers to hold X509 certificates. |
| JVM default Secure Random |
| SecureRandom specification. |
| "TLS" |
| Protocol Name. Most common example are "SSL", "TLS" or "TLSv1". |
| JVM default Trust Managers |
| TrustManagers to validate peer X509 certificates. |
| | 2.2.7 | specifies if HttpsURLConnection.getDefaultSSLSocketFactory() should be used to create https connections. If ' |
| | 2.2.7 | This attribute specifies if HttpsURLConnection.getDefaultHostnameVerifier() should be used to create https connections. If ' |
Wiki Markup |
---|
Note : {{disableCNcheck}} is a parameterized boolean, you can use a fixed variable {{true}}\|{{false}} as well as a [Spring externalized property|http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-factory-placeholderconfigurer] variable (e.g. {{${disable-https-hostname-verification\}}}) or a [Spring expression|http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/expressions.html#expressions-beandef] (e.g. {{#{systemProperties\['dev-mode'\]\}}}). |
Sample :
...
Please see TLS Configuration page for more information.
Using WSDL
Namespace
The WSDL extension elements used to configure an HTTP client are defined in the namespace http://cxf.apache.org/transports/http/configuration
. It is commonly referred to using the prefix http-conf
. In order to use the HTTP configuration elements you will need to add the line shown below to the definitions
element of your endpoint's WSDL document.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<definitions ...
xmlns:http-conf="http://cxf.apache.org/transports/http/configuration
|
The client
element
The http-conf:client
element is used to specify the connection properties of an HTTP client in a WSDL document. The http-conf:client
element is a child of the WSDL port
element. It has the same attributes as the client
element used in the configuration file.
Example
The example below shows a WSDL fragment that configures an HTTP client to specify that it will not interact with caches.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<service ...>
<port ...>
<soap:address ... />
<http-conf:client CacheControl="no-cache" />
</port>
</service>
|
Using java code
How to configure the HTTPConduit for the SOAP Client?
First you need get the HTTPConduit from the Proxy object or Client, then you can set the HTTPClientPolicy, AuthorizationPolicy, ProxyAuthorizationPolicy, TLSClientParameters.
Code Block | ||||
---|---|---|---|---|
| ||||
import org.apache.cxf.endpoint.Client;
import org.apache.cxf.frontend.ClientProxy;
import org.apache.cxf.transport.http.HTTPConduit;
import org.apache.cxf.transports.http.configuration.HTTPClientPolicy;
...
URL wsdl = getClass().getResource("wsdl/greeting.wsdl");
SOAPService service = new SOAPService(wsdl, serviceName);
Greeter greeter = service.getPort(portName, Greeter.class);
// Okay, are you sick of configuration files ?
// This will show you how to configure the http conduit dynamically
Client client = ClientProxy.getClient(greeter);
HTTPConduit http = (HTTPConduit) client.getConduit();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setConnectionTimeout(36000);
httpClientPolicy.setAllowChunking(false);
httpClientPolicy.setReceiveTimeout(32000);
http.setClient(httpClientPolicy);
...
greeter.sayHi("Hello");
|
How to use HTTPConduitConfigurer?
In certain cases, the HTTPConduit could be recreated (for example when using the FailoverFeature) and therefore losing the preconfigured policies. To overcome that, the HTTPConduitConfigurer has been introduced. Here is an example of how it could be used.
Code Block | ||||
---|---|---|---|---|
| ||||
HTTPConduitConfigurer httpConduitConfigurer = new HTTPConduitConfigurer() {
public void configure(String name, String address, HTTPConduit c) {
|
...
...
<http-conf:conduit
name="{http://example.com/}HelloWorldServicePort.http-conduit">
<!-- deactivate HTTPS url hostname verification (localhost, etc) -->
<!-- WARNING ! disableCNcheck=true should NOT be used in production -->
<http-conf:tlsClientParameters disableCNcheck="true" />
...
</http-conf:conduit>
...
Using WSDL
Namespace
The WSDL extension elements used to configure an HTTP client are defined in the namespace http://cxf.apache.org/transports/http/configuration
. It is commonly referred to using the prefix http-conf
. In order to use the HTTP configuration elements you will need to add the line shown below to the definitions
element of your endpoint's WSDL document.
...
<definitions ...
xmlns:http-conf="http://cxf.apache.org/transports/http/configuration
The client
element
The http-conf:client
element is used to specify the connection properties of an HTTP client in a WSDL document. The http-conf:client
element is a child of the WSDL port
element. It has the same attributes as the client
element used in the configuration file.
Example
The example below shows a WSDL fragment that configures an HTTP clientto specify that it will not interact with caches.
...
<service ...>
<port ...>
<soap:address ... />
<http-conf:client CacheControl="no-cache" />
</port>
</service>
Using java code
How to configure the HTTPConduit for the SOAP Client?
First you need get the HTTPConduit from the Proxy object or Client, then you can set the HTTPClientPolicy, AuthorizationPolicy, ProxyAuthorizationPolicy, TLSClientParameters, and/or HttpBasicAuthSupplier.
Code Block | ||
---|---|---|
java | java | import org.apache.cxf.endpoint.Client; import org.apache.cxf.frontend.ClientProxy; import org.apache.cxf.transport.http.HTTPConduit; import org.apache.cxf.transports.http.configuration.HTTPClientPolicy; ... URL wsdl = getClass().getResource("wsdl/greeting.wsdl"); SOAPService service = new SOAPService(wsdl, serviceName); Greeter greeter = service.getPort(portName, Greeter.class); // Okay, are you sick of configuration files ? // This will show you how to configure the http conduit dynamically Client client = ClientProxy.getClient(greeter); HTTPConduit http = (HTTPConduit) client.getConduit(); HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy(); httpClientPolicy.setConnectionTimeout(36000); httpClientPolicy.setAllowChunking(false); httpClientPolicy.setReceiveTimeout(32000); http c.setClient(httpClientPolicy); } } ... greeter bus.sayHi("Hello"setExtension(httpConduitConfigurer, HTTPConduitConfigurer.class); |
How to override the service address ?
If you are using JAXWS API to create the proxy obejct, here is an example which is complete JAX-WS compliant code
Code Block | ||||
---|---|---|---|---|
| ||||
URL wsdlURL = MyService.class.getClassLoader
.getResource ("myService.wsdl");
QName serviceName = new QName("urn:myService", "MyService");
MyService service = new MyService(wsdlURL, serviceName);
ServicePort client = service.getServicePort();
BindingProvider provider = (BindingProvider)client;
// You can set the address per request here
provider.getRequestContext().put(
BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
"http://my/new/url/to/the/service");
|
...
Here is another way which takes advantage of JAXWS's Service.addPort() API
Code Block | ||||
---|---|---|---|---|
| ||||
URL wsdlURL = MyService.class.getClassLoader.getResource("service2.wsdl");
QName serviceName = new QName("urn:service2", "MyService");
QName portName = new QName("urn:service2", "ServicePort");
MyService service = new MyService(wsdlURL, serviceName);
// You can add whatever address as you want
service.addPort(portName, "http://schemas.xmlsoap.org/soap/", "http://the/new/url/myService");
// Passing the SEI class that is generated by wsdl2java
ServicePort proxy = service.getPort(portName, SEI.class);
|
...
The following table lists the cache control directives supported by an HTTP client.
Directive | Behavior |
---|---|
no-cache | Caches cannot use a particular response to satisfy subsequent requests without first revalidating that response with the server. If specific response header fields are specified with this value, the restriction applies only to those header fields within the response. If no response header fields are specified, the restriction applies to the entire response. |
no-store | Caches must not store any part of a response or any part of the request that invoked it. |
max-age | The consumer can accept a response whose age is no greater than the specified time in seconds. |
max-stale | The consumer can accept a response that has exceeded its expiration time. If a value is assigned to max-stale, it represents the number of seconds beyond the expiration time of a response up to which the consumer can still accept that response. If no value is assigned, it means the consumer can accept a stale response of any age. |
min-fresh | The consumer wants a response that will be still be fresh for at least the specified number of seconds indicated. |
no-transform | Caches must not modify media type or location of the content in a response between a provider and a consumer. |
only-if-cached | Caches should return only responses that are currently stored in the cache, and not responses that need to be reloaded or revalidated. |
cache-extension | Specifies additional extensions to the other cache directives. Extensions might be informational or behavioral. An extended directive is specified in the context of a standard directive, so that applications not understanding the extended directive can at least adhere to the behavior mandated by the standard directive. |
A Note About Chunking
There are two ways of putting a body into an HTTP stream:
...
- Many proxy servers don't understand it, especially older proxy servers. Many proxy servers want the Content-Length up front so they can allocate a buffer to store the request before passing it onto the real server.
- Some of the older WebServices stacks also have problems with Chunking. Specifically, older versions of .NET.
- proxy servers. Many proxy servers want the Content-Length up front so they can allocate a buffer to store the request before passing it onto the real server.
- Some of the older WebServices stacks also have problems with Chunking. Specifically, older versions of .NET.
If you are getting strange errors (generally not soap faults, but other HTTP type errors) when trying to interact with a service, try turning off chunking to see if that helps.
When to set custom headers
If you use a custom CXF interceptor to set one or more outbound HTTP headers then it is recommended to get this interceptor running at a stage preceding the WRITE stage, before the outbound body is written out.
Otherwise the custom headers may get lost. The headers may get retained in some cases even if they are added after the body is written out, example, when a chunking threshold value (4K by default) has not been reached,
but relying on it for the headers not to be lost is brittle and should be avoided.
Asynchronous HTTP Conduit
Please see Asynchronous HTTP Conduit page for more informationIf you are getting strange errors (generally not soap faults, but other HTTP type errors) when trying to interact with a service, try turning off chunking to see if that helps.