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
The service browser allows you to test your Amfphp services without any client code. See using the Back Office for info on how to use and access it. Making a JSON request(« call JSON ») allows you to see the response regardless if it’s malformed or not, whereas this shall not work with making an AMF request (« Call AMF »). So start with JSON, then if that works, try with AMF.
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 error 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 with AMF requests
The following issues provoke malformed responses, which means that AMF clients can not parse them.
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.