Your server should obviously run PHP 5.1 or more without any issues. If you have any warnings that are printed like for example a message about your timezones, then Amfphp will not be able to output properly formed messages. Your server should be configured so that making requests to a folder defaults to index.php, because the documentation and examples assume this. Otherwise you must direct your requests to <unzipped>/Amfphp/index.php.
A Good Workflow for Developing Services for Amfphp
Here are a few suggestions to help you use Amfphp with as little pain as possible. The best is to use them chronologically, but feel free to skip and blend as necessary.
use unit tests
We advise you to test your PHP code using purely PHP methods first. For this unit tests are very good. PHPUnit is the best PHP unit testing framework available at the time of writing. It bugs and freaks out if you throw anything complicated at it, but if you keep things simple it will work properly. Amfphp uses PHPUnit extensively.
use the service browser
You can open a browser tab at the gateway address, and if you have the AmfphpServiceBrowser plugin (it’s enabled by default) you can try your services from there. if your amfPHP directory is http://localhost/amfphp-xxx/Amfphp/ , just open that url with your browser and you should see the service browser. It allows you to test your services. If you have issues, print_r and echo work, and if you have an error in your PHP code enable error displaying(in your PHP settings) and they will show up.
try with your client
Your client receives serialized data. If you use echo, print_r, or if PHP outputs an error message, this means your serialized data will be malformed.
If you are using Flash and NetConnection, this will provoke the dreaded « bad version » response error, where the client can’t parse the response.
In flex this comes up as [RPC Fault faultString="Channel disconnected" faultCode="Client.Error.DeliveryInDoubt" faultDetail="Channel disconnected before an acknowledgement was received"]
This is why it is important to fix as many bugs as possible while calling your services with the service browser. It’s more comfortable to debug there.
Use a Packet Sniffer
If you have errors that show up while calling your services with a client but not when using the service browser, you will get meaningless errors and without the proper tools you will be powerless to solve your problem. Read the paragraph above to understand why this happens.
Luckily there are tools that allow you to intercept the data flowing between your client and your server. These are commonly called packet sniffers. More details on this can be found here.
If you need to make sure debug information arrives well formed in your client, use exceptions. They will be caught by Amfphp and sent as well formed messages to your client.
Use the AmfphpErrorHandler plugin
If you need to catch and redirect PHP errors (not exceptions) you can use the AmfphpErrorHandler plugin. It should catch PHP errors and transform them into exceptions. At the time of writing it is a bit experimental so turned off by default. To enable it have a look in Amfphp_Core_Config.
Update: As of Amfphp 2.2, the plugin is enabled by default.
Be careful of crossdomain issues
By default you can only make calls to the same domain that is hosting your client. Furthermore, “www.yourdomain.com” is not the same as plain “yourdomain.com”
Common Issues that will show up only when Using your Client
These issues provoke malformed responses. This is particularly tricky because it doesn’t show up in the service browser. See “try with your client” above for an explanation.
whitespace at the end of your PHP files
If you have whitespace after your ?>, this will provoke an error. Quite a few blog posts cover this issue and how best to handle it, take a look around.
missing “/” at the end of your url
make sure you are calling “http://myserver.com/Amfphp/” and not “http://myserver.com/Amfphp”
forgotten “echo” or “print_r”
Any forgotten “echo” or “print_r” can corrupt the output of Amfphp. Don’t leave them in your code, or better still don’t use them.
What is “NetConnection.Call.BadVe
When Flash receives a malformed response, it gives you this not very helpful error message. Typically there are two groups of causes for this:
- your code has an error in it and your server is configured to display errors.
- you have extra characters hanging around. See “Common Issues that will show up only when Using your Client” above.
In both cases taking a look with a packet sniffer (see above) is your best chance for finding out what is going on.
What is “Channel disconnected before an acknowledgement was received”
It’s the Flex version of “NetConnection.Call.BadVe
Getting information about PHP errors
If you have an error in your PHP code, there are 2 ways for you to retrieve the PHP error messages. Both need you to be able to change your PHP settings, php.ini, or at least to override them in your entry point script(Amfphp/index.php for example)
- in your server logs. See your php.ini for “error_log”, etc.
- in your server response. This is when display_errors is set to “On” You will need a packet sniffer for this(see above).
See the PHP documentation for details on possible configuration values. Also remember to set your log levels correctly for development and production:
- log all when developing
- log selectively for production, and set “display_errors” to off.