The code created to handle the dynamic nature of
Cookies occasionally uses a CONSTANT 'static' Cookie
when it is expected that one retrieved dynamically from
a Set-Cookie HTTP header through use of the of the
'LOAD RESPONSE_INFO HEADER' command would be expected.
It is currently unknown what exact conditions cause the
above problem, but it should be noted that it doesn't
happen for all Web applications and you should be sure
that you are clearing your browsers Cookie Cache for
the domains you are recording before assuming that you
are seeing this problem.
Workaround: hand code the dynamic Cookie SCL where the
problem occurs.
More information and workarounds should be available at
this FAQ location:
http://portal.opensta.org/faq.php?topic=RecordingCookies
Logged In: YES
user_id=19748
Originator: YES
A fix for this issue has been merged into the CVS HEAD. It
will become generally available in the OpenSTA 1.4.4 release.
gwhttp.dll: 1.4.4.6
OpenSTA: 1.4.4.8
Most valid occurrences of this problem turned out to be when
a Cookie contains a space character - although it is
'recommended' that spaces be encoded in Cookies that doesn't
stop badly behaved Web apps not doing this. The Gateway code
was updated to only see the ';' as a Cookie seperator char
and now even badly behaved apps can have their Cookies
recorded correctly.
There are still many times that you may see 'static' CONSTANT
Cookies when you expect dynamic ones, but the Gateway cannot
ever record most of these cases now - they are when the
Gateway can never see a 'Set-Cookie' header because it does
not occur in the HTTP, eg. Cookie set using JavaScript. See
the FAQ URL in the first entry of this bug for more
information, examples, and workarounds for these occasions.