I have the SERVICES/AMFPHP module working perfectly on some test servers that I've set up but am having problems using it on several shared hosting accounts that I have. I'm certain everything is configured properly inside Drupal's admin. XMLRPC services work great. The Drupal installs and flash are identical on all systems - only the hosting environment is different. The flash is calling the gateway url '/services/amfphp' on all the tests I have set up so I don't think it is a security/sandbox issue.
I'm hoping for some guidance on what to do next as far as troubleshooting. Below are examples of what Firebug is telling me about the headers results from the call made by flash. One interesting difference to note is that the non working example sets the Content-Type header to: text/html; charset=utf-8 and also adds the header Transfer-Encoding as chunked. I hacked the code with a header() function to set the content type to application/x-amf but that had no effect.
Working test server header results (os x machine used for staging and developing) :::::
Date Mon, 07 May 2007 06:10:41 GMT
Server Apache/2.0.59 (Unix) PHP/4.4.4 DAV/2 mod_ssl/2.0.59 OpenSSL/0.9.7l
X-Powered-By PHP/4.4.4
Expires Mon, 7 May 2007 01:10:42 GMT
Last-Modified Mon, 07 May 2007 06:10:41 GMT
Cache-Control no-store
Content-Length 588
Pragma no-store
Keep-Alive timeout=15, max=93
Connection Keep-Alive
Content-Type application/x-amf
Non-working example headers for a sample shared hosting account where the call does not work:::
(this server is some linux/apache setup running php 5.1.4 - also tried one with php 4.x... same results )
Date Mon, 07 May 2007 06:09:23 GMT
Server WebServerX
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires Sun, 19 Nov 1978 05:00:00 GMT
X-Powered-By PHP/5.1.4
Last-Modified Mon, 07 May 2007 06:09:23 GMT
Keep-Alive timeout=15, max=49
Connection Keep-Alive
Transfer-Encoding chunked
Content-Type text/html; charset=utf-8
Does this seem like a bug in that it is behaving differently on identical installs on different systems? What other information can I provide that will help troubleshoot this.
Thanks
Eric
Comments
Comment #1
heiax commentedI had the same problem. After investigating a bit, i found out, that amfphp relies on the global HTTP_RAW_POST_DATA. There is a setting in php.ini always_populate_raw_post_data that needs to be set to "On" on some php versions. Furthermore if register_globals is set to "on" amfphp won't work in drupal, because in that situation drupal strips the HTTP_RAW_POST_DATA from the globals array.
Comment #2
squaretone commentedThis is good info to know. Since this is a young module, is there a place that we can begin documenting these quirks while it matures? Would the Handbook entry for the Services module be an appropriate place. It might be a little more cohesive than hunting thru the issue que.
Comment #3
jody lynnA check for these settings could be added to amfphp's hook_requirements function.
Comment #4
snelson commentedI started to add the checks to hook_requirements, but found that ini_get('always_populate_raw_post_data') is false on my machine, which means that it isn't actually required. Also, Drupal already checks to make sure register_globals is off.
- Scott