Because servlet-based endpoints use standard HTTP requests, communicating with clients inside firewalls usually works, as long as the client-side firewall has the necessary ports open. Using the standard HTTP port 80 and HTTPS port 443 is recommended because many firewalls block outbound traffic over non-standard ports.

The protocols that the various client channels use are hard coded. For example, the AMFChannel always uses HTTP, while the SecureAMFChannel always uses HTTPS. One thing to watch for when using a SecureAMFChannel/SecureAMFEndpoint combination is an issue with Internet Explorer related to no-cache response headers and HTTPS. By default, no-cache response headers are enabled on HTTP-based endpoints. This causes problems for Internet Explorer browsers. You can suppress these response headers by adding the following configuration property to your endpoint:

<add-no-cache-headers>false</add-no-cache-headers>

When you have a firewall/reverse HTTP proxy in your deployment that handles SSL for you, you must mix and match your channel and endpoint. You need the client to use a secure channel and the server to use an insecure endpoint, as the following example shows:

<channel-definition id="secure-amf" class="mx.messaging.channels.SecureAMFChannel">
   <endpoint url="https://[firewall ip:port]/{context.root}/messagebroker/amf" 
   class="flex.messaging.endpoints.AMFEndpoint"/>
   <properties>
   <add-no-cache-headers>false</add-no-cache-headers>
   ...

The channel class uses HTTPS to hit the firewall/proxy, and the endpoint URL must point at the firewall/proxy. Because SSL is handled in the middle, you want the endpoint class used by BlazeDS to be the insecure AMFEndpoint and your firewall/proxy must hand back requests to the HTTP port of the BlazeDS server, not the HTTPS port.