HTTP transport header properties best practices

The REQUEST_TRANSPORT_PROPERTIES property and RESPONSE_TRANSPORT_PROPERTIES property can be set on a Java API for XML-based RPC (JAX-RPC) client Stub to enable a Web services client to send or retrieve HTTP transport headers.

Best practice: Use these best practices to enable a Web services client to send or retrieve HTTP transport headers.bprac

 

REQUEST_TRANSPORT_PROPERTIES best practices

Header values format The header values format must be written in the following way:

• Each name=value pair must be separated by a semi-colon (;).

• Each name and its value must be separated by an equal (=) sign.

The following is an example of how the header value must be written:

name1=value1;name2=value2;name3=value3

HashMap values The HashMap values might be parsed before being added to the outgoing request if the outgoing request already contains a header identifier that matches one in the HashMap. The header values in the HashMap are parsed into individual name=value components. A semi-colon (;) separates the components, for example, name1=value1;name2=value2. Each name=value is appended to the outgoing header unless:

 

• The outgoing request header contains a name value.

  In this case, the name=value from the HashMap is silently ignored, preventing a client from overwriting or modifying values for the name value that are already set in the outgoing request header by either the server or the Web services engine.

   

• The HashMap header value contains multiple name values.

  When the HashMap header value contains multiple name values, the first occurrence of the name value is used and the others are silently ignored. For example, if the HashMap header value contains name1=value1;name2=value2;name1=value3, where there are two occurrences of name1, the first value, name1=value1, is used. The other value, name1=value3, is silently ignored.

 

RESPONSE_TRANSPORT_PROPERTIES best practices

HashMap values

Only the HashMap keys are used; the HashMap values are ignored. The values are filled in this HashMap by retrieving the HTTP headers, which correspond to the HashMap keys from the incoming HTTP response. An empty HashMap causes all of the HTTP headers and the associated values to be retrieved from the incoming HTTP response

 

HTTP headers that are processed under special consideration

The following are HTTP headers that are given special consideration when sending and retrieving HTTP responses and requests.

The values in these headers can be set in a variety of ways. For example, some header values are sent based on settings in a deployment descriptor or binding file. In these cases, the value set through REQUEST_TRANSPORT_PROPERTIES overrides the values set any other way.

Header	Send request	Retrieve response
Transfer-encoding	The transfer-encoding header is ignored for HTTP 1.0. When using HTTP 1.1, the transfer-encoding header is set to chunked if the value is chunked.	There is no special processing.
Connection	The connection header is ignored for HTTP 1.0. When using HTTP 1.1, the following values are set: The connection header is set to "close" if the value is set to "close". The connection header is set to "keep-alive" if the value is set to "keep-alive". All other value settings are ignored.	There is no special processing.
Expect	The expect header is ignored for HTTP 1.0. When using HTTP 1.1, the following values are set: The connection header is set to "100-continue" if the value is set to "100-continue". All other value settings are ignored.	There is no special processing.
Host	Ignored	There is no special processing.
Content-type	Ignored	There is no special processing.
SOAPAction	Ignored	There is no special processing.
Content-length	Ignored	There is no special processing.
Cookie The following is a String constant: com.ibm.websphere.webservices.Constants.HTTP_HEADER_COOKIE	The value is sent on the header if it is structured correctly. See the information in this article for Header value format and HashMap values.	There is no special processing.
Cookie2 The following is a String constant: com.ibm.websphere.webservices.Constants.HTTP_HEADER_COOKIE2	See the information in the "Cookie" entry.	There is no special processing.
Authorization	Ignored	There is no special processing.
Proxy-authorization	Ignored	There is no special processing.
Set-cookie The following is a String constant: com.ibm.websphere.webservices.Constants.HTTP_HEADER_SET_COOKIE	There is no special processing.	If the property MAINTAIN_SESSION is set to true, the entire value is saved into SessionContext.CONTEXT_PROPERTY and is sent on subsequent requests in the Cookie header. See the Cookie entry in this table for more information.
Set-cookie2 The following is a String constant: com.ibm.websphere.webservices.Constants.HTTP_HEADER_SET_COOKIE2	There is no special processing.	If the property MAINTAIN_SESSION is set to true, the entire value is saved into SessionContext.CONTEXT_PROPERTY and is sent on subsequent requests in the Cookie header. See the Cookie entry in this table for more information.

 

Example client code

The following is an example of how a Web service a Web services client can be coded to send and retrieve HTTP transport header values:

HashMap sendTransportHeaders=new HashMap(); sendTransportHeaders.put("Cookie","ClientAuthenticationToken=FFEEBCC"); sendTransportHeaders.put("MyRequestHeader","MyRequestHeaderValue"); ((Stub) portType)._setProperty(Constants.REQUEST_TRANSPORT_PROPERTIES, sendTransportHeaders);

HashMap receiveTransportHeaders=new HashMap(); receiveTransportHeaders.put("Set-Cookie", null); receiveTransportHeaders.put("MyResponseHeader", null); ((Stub) portType)._setProperty(Constants.RESPONSE_TRANSPORT_PROPERTIES, 
  receiveTransportHeaders);
 resultString=portType.echoString("Foo");

---

 

Related tasks

Sending HTTP transport headers
Retrieving HTTP transport headers
Implementing extensions to the JAX-RPC and Web Services for J2EE client programming models

 

Reference topic