To inherit Cookie information between 2 services, you can select whether to inherit Cookie information collectively or whether to inherit individually for each Cookie name. The message format for the used header variable differs according to the method selected.

Inheriting Cookie information collectively

• Use adphttp_header_request1.xsd in request message format.
• Use adphttp_header_response1.xsd in response message format.

Inheriting individually in editable status for each Cookie name

• Use adphttp_header_request2.xsd in request message format.
• Use adphttp_header_response2.xsd in response message format.

In either case, to inherit Cookie information from service component A to service component B, map Cookie information (Cookie element) included in the response message of service component A in the request message of service component B and then invoke HTTP adapter.

Inheritance method in each case is described here.

(a) Inheriting Cookie information collectively

All Cookie information is represented by any type in the message format in the following manner. The element name showing Cookie element is "Cookie_types".

 
<xsd:complexType name="http-header-Cookies-type">
  <xsd:sequence>
    <xsd:any namespace="##any"
        processContents="skip" minOccurs="0" maxOccurs="unbounded" />
  </xsd:sequence>
</xsd:complexType>
 

You can collectively inherit Cookie information by mapping any type element parts from the response message of service component A to the request message of service component B.

(b) Inheriting individually in editable status of each Cookie name

Each attribute of Cookie information in the message format is partitioned in XML element attribute in the following manner. The element name showing Cookie element is "Cookie_types".

 
<xsd:complexType name="cookie-type">
  <xsd:simpleContent>
    <xsd:extension base="xsd:string">
      <xsd:attribute name="name" type="xsd:string" use="required"></xsd:attribute>
      <xsd:attribute name="host" type="xsd:string" use="required"></xsd:attribute>
      <xsd:attribute name="path" type="xsd:string" use="optional"></xsd:attribute>
    </xsd:extension>
  </xsd:simpleContent>
</xsd:complexType>
 

While mapping from the response message of service component A to the request message of service component B, you can see Cookie name and inherit individually.

This section describes transformation from HTTP response header to response message and the process of transformation from the request message to HTTP request header.

Process of transformation from HTTP response header to response message

The value of each Set-Cookie header passed from service component A to HTTP response header is stored in Cookie element of the response message. Each attribute of Set-Cookie header is set in the attribute value of Cookie element.

If multiple Set-Cookie headers exist, Cookie element is generated for each Set-Cookie header.

Examples of transformation from HTTP response header to the response message (header) are as follows:

• Set-Cookie header of HTTP response header
  

  Set-Cookie: AAA=1234; expires=Sat, 27-Oct -2012 10:00:00 GMT; path=/ Set-Cookie: BBB=5678; expires=Sat, 27-Oct -2012 10:00:00 GMT;

• Response message (header) after generation
  

  <Cookies> <Cookie name="AAA" path="/" host="hostname:80#">AAA=1234; expires=Sat, 27-Aug-2011 10:00:00 GMT; path=/</Cookie> <Cookie name="BBB" host="hostname:80#">BBB=5678; expires=Sat, 27-Aug-2011 10:00:00 GMT</Cookie> </Cookies>

Note#

Host name and port number used to connect to the service component are stored in host attribute.

If you cannot acquire path attribute from Set-Cookie header, processing occurs without path attribute being added in the response message (header). In such cases, path attribute value is handled as "/".

Process of transformation from request message to HTTP request header

Cookie information passed as the request message of HTTP adapter is set in HTTP request header as the sending target if it meets both of the following conditions:

• Values (host name and port number) set in service component URI and Cookie element host attribute match completely.
• The front part of the path set in Cookie element path attribute matches with service component URI.

Example: If service component URI is http://localhost:80/abc/xyz

• Cookie information host attribute value=localhost:80, path attribute value=/abc ? Sent
• Cookie information host attribute value=somehost:80, path attribute value=/abc ? Not sent
• Cookie information host attribute value=localhost:443, path attribute value=/abc ? Not sent
• Cookie information host attribute value=localhost:80, path attribute value=/xyz ? Not sent
• Cookie information host attribute value=localhost:80, path attribute value=/abc/xyz/def ? Not sent

If multiple Cookie information items exist, they are transformed to collective Cookie header in the following manner.

An example of transformation from the request message (header) to HTTP request header is as follows:

• Cookie element of request message (header)
  

  <Cookies> <Cookie name="AAA" path="/" host="hostname:80">AAA=1234; expires=Sat, 27-Oct-2012 10:00:00 GMT; path=/</Cookie> <Cookie name="BBB" host="hostname:80">BBB=5678; expires=Sat, 27-Oct-2012 10:00:00 GMT</Cookie> </Cookies>

  Cookie element name uses only locale name. If Cookie information in the header request message is collectively inherited from the header response message, name space of Cookie element of the header request message becomes the header response message. However, it is handled correctly as the sending target, since the name space is not seen.
  
• HTTP request header after generation
  

  Cookie: AAA=1234; BBB=5678

  Note

  • If you set multiple Cookie elements containing different path attribute values, path attribute value is in detailed order and Cookie information is set in HTTP header.
    (Example) If Cookie element containing NAME1=VALUE1 path=/, NAME2=VALUE2 path=/xyz value is set:
    Cookie: NAME2=VALUE2; NAME1=VALUE1
    
  • If Cookie information that cannot be processed normally is received, analysis is skipped and processing continues.
  • Also see the precautions shown in "2.2.4(4) Notes".