Cookie handling: -j modifies Set-Cookie path attribute

In addition to providing a junction identifier cookie to the browser, junctions configured with the -j option, or listed in a junction mapping table, also support the handling of non-domain cookies sent with responses from the back-end application.

If a Set-Cookie header in a response from the server contains a path attribute (such as path=/xyz), the browser returns the cookie only when a request URL (activated from the returned page) begins with this path (such as /xyz/memo.html).

Problem:

When the junction environment contains mixed solutions for handling visible and embedded URLs in responses, the ability of the browser to return cookies can be compromised. For example, standard WebSEAL filtering of visible server-relative URLs normally adds the junction name to the value of the path attribute of a server cookie (for example, path=/jct/xyz), in addition to modifying the URL itself. This match between URL path name and the cookie path value allows the browser to return the cookie when the link is activated by the user.

However, the -j junction-cookie-based solution adds the junction name to a URL only after the link (URL) has been activated by the user. When the link is activated, the pre-modified URL path name (/xyz/memo.html) does not match the Set-Cookie path attribute value (path=/jct/xyz). The server cookie is not returned with the request.

Solution:

The -j option converts the value of the path attribute for any server cookie to "/" (for example, path=/). Because all server-relative path names begin with a "/", all server cookies are returned regardless of the requirements of the original path attribute specifications.

Parent topic: Handling cookies from servers across multiple -j junctions