Table of contents:
- What's new
- Installing Remoting components
- Installing AMFPHP
- Testing AMFPHP
- 10,000 foot view of Remoting
- Creating Remoting methods
- Method table reference
- Helper classes
- NetDebug
- Authenticate
- DateWrapper
- Datatypes
- Class mapping
- Security
- Authentication
- Sending recordsets
- Manual recordsets
- Pageable recordsets
- Consuming web services (SOAP)
- Other platforms
- FAME
- Flex
- FlashCom
- The service browser
- Debugging
- Debugging primer
- NetConnection debugger
- Debugging proxies
- NetDebug::trace and exceptions
- Common confusing errors
- Deploying
- Credits
Debugging
Debugging Flash Remoting applications can be fast and simple if you read through this overview of debugging techniques and common errors.
debuggateway.php
Pointing to the debug gateway instead of the regular gateway (introduced in amfphp 1.1) should point out most fatal errors provided you are using the NetConnection debugger.
Get access to the error_log
Getting access to the error log is the second step to take if using debuggateway.php didn't help (for example, if the error you are getting is related to sessions). If you skipped enabling the error_log in the installation guide, do so now.
NetConnection.Call.BadVersion, Buffer.Underflow
An error that will happen every once in a while is receiving a NetConnection.Call.BadVersion error in the NetConnection debugger. You can usually catch the source of this error by pointing to the debug gateway instead of the regular one. What happens is that the AMF message sent from AMFPHP to Flash was malformed. There are several possible reasons:
- A syntax error is causing PHP to write the error to standard output. ASCII output is not acceptable AMF, hence the error. There is an easy way to catch this. Load the service class from a web browser directly. If there is a syntax error, PHP should give you the line number that is causing the problem.
- A runtime error is causing AMFPHP to die with an error. This can be a bit more difficult to debug. Open the error log, open it and you should see where the error is coming from.
- Something is is outputting random data to the standard output, for example echo, print and such. This should have a much lesser chance of happening in 1.0 as there is an output buffer set up in loose mode to prevent these to reaching standard output. The only thing you should be careful about is returns (line feeds) before or after <?php ?> at the beginning and end of the gateway.php file.
Another common error is NetConnection.Buffer.Underflow. This could happen if you exit without error from a method for example using die(). There are subtle other cases where this might also happen, such as if you hard code the return type inappropriately.
AMFPHP not answering at all
Another error from experience is that AMFPHP just does not answer at all (in the network debugger, the request is sent but no answer or no error messages appears). One common reason could be that the constructor or the methodTable of the remoting class is faulty. You should be able to find out where the error is coming from by looking at the error_log or by pointing to the debug gateway.
Persistent problems
If worse comes to worse, a good solution can be to use a packet sniffer with support for AMF. Two good options are Charles and ServiceCapture.