The user sends an HTTP connection request to an SWP. The HTTP request must contain:
The URL that calls the SWP, such as http://swp-server:port/webproxy/proxy, where swp-server is the name of the server, port is the port number, and webproxy/proxy is an alias for the SWP as it was defined when it was deployed.
The name of the application, such as “Sybase.” See “Defining applications” for a definition of applications.
The index of the application’s URL. The index is a number, 0 to n, that represents the sequential order of the URL in the URL index. The URL index is a comma-separated list of URLs that comprise an application. The user does not have to specify an index; however, if the application’s path data contains a number, the SWP interprets it as an index. Also, if an index number is not specified, the value defaults to 0.
Any data that tells the SWP what the HTTP request is requesting, such as a Web page, an image, or an application. For example, webpage.html or picture.gif.
For example, the user may send this HTTP request:
http://swp-server:9008/webproxy/proxy/Sybase/0/webpage.html
An SWP scans the request,
strips out the information that is used to connect to the SWP, (swp-server:9008/webproxy/proxy),
parses and extracts the application name and the URL index (Sybase/0),
and appends the requested data information (webpage.html)
to generate a URL that can be interpreted by the back-end data server.
The result is:
http://www.sybase.com/webpage.html
When a back-end application sends a request to store or retrieve a cookie, an SWP intercepts the request and does not forward the request to the client. Instead, an SWP acts as a temporary cookie repository for application-level cookies. This makes the session appear seamless to users because they are not prompted to accept cookies from applications as they navigate through the different applications proxied by an SWP. When the user’s session times out, all cookies stored for that session are deleted.
For example, if an application stores user-preference information in a cookie, an SWP intercepts those cookies and stores them for the duration of the session. When the session is closed, all user preferences are lost.
If the user has the appropriate permissions (see “Implementing single sign-on capabilities”), the URL is sent to the appropriate server. The server then returns the requested application as HTML or binary data.
If the response data is in binary format, an SWP returns the data unchanged. If the data is in HTML format, and if an SWP has been configured to do so, the SWP sends HTML data through filters to ensure the content does not contain any embedded links that allow the user to access the back-end data directly.
