BlazeDS Gotcha: default Cookie handling in proxy service only accepts RFC 2109 cookies
I found a very subtle behaviour in BlazeDS yesterday. I assume that this also applies to LCDS, haven't tested it though.
BlazeDS comes with a proxy service that allows you to solve the crossdomain data loading restrictions of Flash Player (i.e. a SWF on server A may not load data from a different domain B, unless domain B allows the SWF explicitely). To proxy the requests, BlazeDS uses the famous HTTPClient library. I used the proxy in several projects so far and never had any issues with it - until yesterday...
In a current project BlazeDS is used to proxy between a Flex client application and a hosted Adobe Connect account that lives on the admin.emea.acrobat.com sub-domain. When a user logs in to the Connect system, the Connect server sends back a Cookie with the domain set to .acrobat.com (notice the leading dot). However, this Cookie is ignored by the BlazeDS proxy service and you'll get a warning message in the server logs similar to: "Cookie rejected: "$Version=0; BREEZESESSION=Sbreez8chuv13an7trwkon; $Path=/; $Domain=.acrobat.com". Domain attribute ".acrobat.com" violates RFC 2109: host minus domain may not contain any dots" - this means subsequent calls made by BlazeDS will not send any Cookies with the request which mixes up things badly as you can imagine.
So - the Cookie returned by acrobat.com is not RFC 2109 compliant because the RFC does not allow compliant clients to accept Cookies which domain attribute is set to value starting with a dot (i.e. .acrobat.com) when the Cookie itself was set by a domain with a subdomain that contains a dot (i.e. admin.emea is the subdomain)... everyone got that?
The underlying HTTPClient library used by BlazeDS by default uses a Cookie policy that only accepts RFC 2109 compliant Cookies (which is a rather strict setting). In contrast, all modern browsers use a somewhat lax Cookie interpretation to maximize compability with existing web sites. So while everything works nicely in a browser it does not with BlazeDS' proxy service.
I was able to solve this issue by extending the default HTTPProxyAdapter that comes with BlazeDS. This custom Adapter sets the CookiePolicy used by the HTTPClient to BROWSER_COMPATIBILITY and this actually ensures that the Cookie returned by admin.emea.acrobat.com is accepted - puh :)
I also logged a bug for this in the BlazeDS bugbase and attached my workaround for it. So if you want to see this fixed in BlazeDS feel free to vote for it.
Dirk.
Hi there, First of all you have some great info on your blog. These days I am experimenting with proxy services using blazeds, but I couldn't really get through it. Here you can read my problem statement: http://stackoverflow.com/questions/7583303/using-proxy-webservice-with-adobe-air-blazeds
It would be great if you could help me with a pointer towards solution. Thanks.