About Sun Adapter for HTTPS

This topic provides conceptual information about HTTPS and its Sun Java CAPS Adapter.

About HTTP and HTTPS

HTTP (hypertext transfer protocol) is the set of rules used for transferring files (text, graphic images, sound, and video) over the Web. When a user opens a Web browser, the user is indirectly making use of HTTP. HTTP is an application protocol that runs on top of the TCP/IP suite of protocols.

In addition to the files that it serves, every Web server contains an HTTP daemon—a program that waits for HTTP requests and handles them when they arrive. A Web browser is an HTTP client, sending requests to server machines. When the user enters a URL or clicks on a hypertext link, the browser builds an HTTP request and sends it to the IP address indicated by the URL. The HTTP daemon in the destination server machine receives the request and sends back the requested file or files associated with the request.

HTTPS (hypertext transfer protocol over secure socket layer—or HTTP over SSL) is a Web protocol that encrypts and decrypts user page requests as well as the pages that are returned by the Web server. HTTP uses port 443 instead of HTTP port 80 in its interactions with the lower layer TCP/IP. SSL uses a 40-bit encryption key algorithm, which is considered an adequate level of encryption for commercial exchange.

When an HTTPS request is sent by a browser—usually by clicking a link that begins with https://—the client browser encrypts the request and sends it to the Web server. The acknowledgement sent by the Web server is also sent using encryption, and is decrypted by the client browser.

About the HTTPS Adapter

The HTTPS Adapter enables Sun Java CAPS ESB to communicate with client and server applications over the Internet using HTTP, either with or without SSL.

HTTP Messages

An HTTP message has two parts: a request and a response. The message header is composed of a header line, header fields, a blank line, and an optional body (or data payload). The response is made up of a header line, header fields, a blank line, and an optional body (or data payload). HTTP is a synchronous protocol, that is, a client makes a request to a server and the server returns the response on the same socket.

Web Browser Cookies

A cookie is an HTTP header, which is a key-value pair in the header fields section of an HTTP message.

The Set-Cookie and Cookie headers are used with cookies. The Cookie-request header is sent from the server in request for cookies on the client side. An example of a Cookie-request header is:

Set-Cookie: sessauth=44c46a10; expires=Wednesday, 27-Sep-2006
03:59:59 GMT

In this example, the server requests that the client store the following cookie:

sessauth=44c46a10

Everything after the first semi-colon contains additional information about the cookie, such as the expiration date. When the Adapter sees this header, it extracts the cookie sessauth=44c46a10 and returns it to the server on subsequent requests. The Adapter prepends a cookie header to the HTTP request, for example:

Cookie: sessauth=44c46a10

Each time the Adapter sends a request to the same server during a session, the cookie is sent along with the request.

Cookie Expiration Date Checking

The HTTPS Adapter checks time-limited cookies with expiration dates to ensure that they have not expired. If they have expired, the cookie is removed and is not resent to the originating server. As a result, the session state is removed.

The following standard expiration date formats are recognized by the HTTPS Adapter:

"Sun, 06 Nov 1994 08:49:37 GMT"            ;RFC 822, updated by RFC 1123
"Sunday, 06-Nov-94 08:49:37 GMT"         ;RFC 850, obsoleted by RFC 1036
"Sunday, 06-Nov-1994 08:49:37 GMT"                  ;RFC 1036
"Sun Nov  6 08:49:37 1994"                   ;ANSI C’s asctime()

If the expiration date is in another format, the Adapter does not recognize the expiration date. Instead, it treats the cookie as if it does not have an expiration date.

GET and POST Methods

The GET method can be used in client mode to retrieve a page specified by the URL or to retrieve information from a form-based Web page by submitting URL-encoded key and name value pairs. In the latter case, the page must support the GET method.

The following example shows a URL-encoded query string:

http://.../bin/query?p=seebeyond+integrator

The URL specifies the search page and the name-value pair for the search. The question mark (?) indicates the beginning of the name-value pair encoding. In the previous example, the name portion of the query is “p,” and the value to search is “seebeyond integrator.” A query can consist of one or more of these name-value pairs.

See the official HTTP Specification for complete information.

The POST method is more versatile, in that it supports form-based requests, as well as sending large amounts of data. The POST method does not have the size-limitation maximum of 255 or 1024 characters (depending on the Web server), which the GET method has. As with GET, the Web page must support the POST method in order to use POST.

Taking the previous URL as an example, if you specify the following URL:

http://.../bin/query

Then, you can specify the name-value pair separately. The HTTP client allows for the specification of the URL and n-number of value pairs via its methods.

Sample HTTP Exchange in Client Mode

To retrieve the file at the following URL:

http://www.myhost.com/path/file.html

First open a socket to the host www.myhost.com, port 80 (use the default port of 80 because none is specified in the URL). You can then send a request through a socket that looks like the following example:

GET /path/file.html HTTP/1.0                (Request Header Line)
User-Agent: HTTP(S)Adapter                  (Request Header field)

The server sends a response back through the same socket. The response could look like the following example:

HTTP/1.0 200 OK               (Response Header Line)
Date: Fri, 31 Dec 1999 23:59:59 GMT                 (Response Header Field)
Content-Type: text/html             (Response Header Field)
Content-Length: 1354                 (Response Header Field)
[blank line here]
<html>                  (Response payload)
<body>
<h1>Happy New Millennium!</h1>
(more file contents)
  .
  .
  .
</body>
</html>

After sending the response, the server closes the socket.

Sample HTTP Exchange in Server Mode

To listen for a request from an HTTP client, the HTTPS Adapter in server mode listens on the port configured for your Integration Server (18001 by default). The HTTPS Adapter receives the request and processes it according to the logic you create in your Collaboration or Business Process.

In a simple example, the HTTPS Adapter receives a request from the following form:

<HTML><HEAD><TITLE>HTTP Server JCE Test Page</TITLE></HEAD>
<BODY>
<FORM ACTION="http://localhost:18001/
    Deployment1_servlet__MyServlet/
    _MyServlet" METHOD=POST>
<TABLE>
<TR><TD>What’s your name?</TD><TD><INPUT NAME=fname></TD></TR>
<TR><TD></TD><TD></TD></TR>
</TABLE>
<BR>
<CENTER><INPUT TYPE=submit VALUE="Submit"></CENTER>
</FORM>
</BODY>
</HTML>

When the client enters a name in a browser and clicks Submit, the HTTPS Adapter server returns a simple response (according to the logic in the Collaboration or Business Process).