xmlhttprequest POST from subdomain 405 error

[m1k3ry4n]

I'm using OpenLayers to send a POST request to a PHP script within my subdomain and I get the http error 405 Method Not Allowed.

I'm using OpenLayer's Request namespace to do this.

When I create Request namespace it looks something like:

OpenLayers.Request.POST({
url:"/sites/default/files/scripts/print/print.php",
data:OpenLayers.Util.getParameterString({
width:size.w,
height:size.h
}),
headers:{'Content-Type':'application/x-www-form-urlencoded'},
callback: processResults
});

On my local Ubuntu machine within Drupal, it works fine. Now that I'm up on the FQ server, on a subdomain and in Drupal, I'm getting this error. (The main www is also a Drupal installation. This Drupal installation resides in www/example.)

I'm guessing that the subdomain/Drupal is the crux of the problem, and there might be a magic setting somewhere within FQ that I don't know about that would solve this.

Anyone have any ideas?

[Terra]

Please send a message to the service desk stating which domain you are having this '405' status return on...

Most likely you are hitting a blanket security control in place to protect sites from exploitable xmlrpc.php...

[m1k3ry4n]

Will do. Thanks.

[Terra]

For those following this thread, the final conclusion on this was the 405 status code was a result of a Drupal security setting in a .htaccess file...

Specifically:
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006

Which in turn disabled the ability for PHP to execute any scripts...

It was no different from trying to send POST data to a static file, for which Apache would respond with, "Hey - why are you sending dynamic data to a static file that can't process it?!? 405 it is for you netizen!!!"

[m1k3ry4n]

Thanks, Terra.

As it turns out, I was not doing things The Drupal Way ^TM and I got busted.

I had my script in the sites/default/files directory. This is a location where users can upload content if you allow that sort of thing. There's the potential security risk of someone uploading a malicious script there, so the auto-generated .htaccess file effectively puts the hex on POSTing. When this was implemented, it seemed to upset a few people. But there is a simple way around it, and you don't even need to reconfigure your server or hack apart your core Drupal files.

What you are supposed to do when you want to add things like PHP scripts to Drupal is create a module. As it turns out in the case of wanting to run a script you don't even need to strictly create a module, you can just put the script in the modules directory sites/all/modules. You'd probably want to at least create a directory for it: sites/all/modules/custom/yourscriptdirectory.

Drupal has some documentation on creating modules, but typically their documentation is lacking. I've found the book Learning Drupal 6 Module Development to be much more helpful.

Files in sites/all/modules directory are web accessible and since technically only a user with FTP/SSH access could put something there, I assume Drupal deemed it a safe location, so there's no .htaccess file with the SetHandler line.