It may be something more complicated than this, but let's
cover the basics
for HTTPS first before we start tracking down session
cookies...
1. If you need to make a secure connection from the Flash
Player, then the
SWF should be loaded via HTTPS. If you're using an HTML
wrapper be sure that
the movie url for the SWF is HTTPS - if it's a relative URL
this would mean
that the HTML wrapper itself would have to be loaded via
HTTPS.
2. MSIE has problems with certain HTTP response headers when
using SSL -
various combinations of Pragma: no-cache, Cache-Control:
no-cache, or Expires
response headers can cause problems depending on the version
of HTTP, whether
chunked or gzip encoding is being used, and the version of
MSIE (with the
most problems seem to occur with MSIE 6).
3. If you're using a crossdomain.xml policy file, watch out
for a Firefox
only bug where by if the Flash Player requests a
crossdomain.xml from a URL
that specifies a port and is challenged by Basic Auth the
subsequent request
will not work.
In general, when debugging HTTP/HTTPS issues it pays to use a
sniffer to
watch the traffic between the client and the server. Since
you're having
issues with HTTPS, you'll probably need to use a client-side
proxy to do
the sniffing for you. Paros Proxy is a good example of a
simple sniffer that
you can easily configure MSIE to use as a proxy and thus
watch the HTTP headers
and bodies for the request and response before they are sent
encrypted via
HTTPS.
Hello kgeiwitz,
> Pete,
>
> LCDS 25
>
> When I switch the protocol to http, so I can see it in
the sniffer,
> everything works fine (tomcat and jrun).
>
> So . . . maybe it has something to do with https ? ? ?
(still not
> sure why it works in jrun but not in tomcat)
>
> I tried adding the JSESSIONID to the response header of
the jsp that
> has the swf, and as a parameter of the swf . . . neither
worked.
>