Browsers don't generally relay HTTP headers. You can certainly send them to the browser, but they won't be returned. For that you need a cookie (a type of header actually). HTTP cookies were created to allow browsers to maintain application "state" and are ~always~ relayed back to the server once they're set.
ACCESS::respond 302 Location $url "Set-Cookie" "cookiename=value; path=/"
There are a few additional options that you can use when setting a cookie (domain, expires, secure, and httponly) and all are "scoping" mechanisms that tell the browser under what condition to send, or not to send a cookie (ie. the URI matches a specific path, the URL matches a specific domain, the cookie isn't expired, the cookie should only be sent over secure connections, and the cookie should not be accessible to client side script, respectively).
Now here's where it gets a little tricky. By default, browsers will generally only relay cookies in the "domain" in which they're set. It's an interpretation of the "same origin policy" and is an important security feature for browsers. You wouldn't want a cookie sent on an MSN site to be used on a Goole site. I say generally because there are ways around this, but most of the workarounds are not easy. If the servers are in the same domain, that is, the same second-level or higher domain (ex. www.domain.com, shop.domain.com, and vote.domain.com = *.domain.com), then you can specify a domain option in the Set-Cookie header that will permit the browser to send the cookie to any matching domain.
"Set-Cookie" "cookiename=value; path=/; domain=.domain.com"
But if that's not the case between these two services, then sending a cookie is going to be tough. Of the workarounds to the cross domain restriction, one reliable and often used option is a URI. Assuming this isn't private data, and who would put private data in a cookie anyway (sarcasm but a sad reality) then a URI would be an easy option:
ACCESS::respond 302 Location "https://site.otherdomain.com/?data=[URI::encode [b64encode ...some data...]]"
Here I've taken the value I want to send, base64-encoded it, URI-encoded it, and then added it to a query string parameter in the HTTP redirect URI. I could have optionally encrypted it, but again who puts sensitive data in a cookie anyway. If the other side was also an F5 (though not expressly required) it'd be a simple matter of reversing that process to fetch the data:
when HTTP_REQUEST {
if { [URI::query [HTTP::uri] data] ne "" } {
set data [b64decode [URI::decode [URI::query [HTTP::uri] data]]]
}
}
when HTTP_RESPONSE {
if { [info exists data] } {
HTTP::cookie insert name "data-from-other-site" value $data
unset data
}
}
If the "data" query string exists in the request (at the other site), we extract it, decode it, optionally do something with it in the request, and then insert it as a local cookie back to the browser. That is of course just one option.
Cirrus
