Allow for valid values of $_SERVER['CONTENT_TYPE'] in Rest Server

attaching patch for review

@voxpelli thanks I am still getting to know the workings of this module.

Am I correct though in thinking that the "POST" case should not be testing the value of $_SERVER['CONTENT_TYPE'] directly?

I have new patch that does the "self::parseContentHeader" call before the switch statement. This way the "CASE" can test the $type['value'] returned.

I also removed the return statement that I added.

@voxpelli, ok I figured out why my current situation is not working. I think it is combination of some special code I am running and Services code having the problem I specified in number #1.

I handling a service request from an outside app that is trying to create Users. The app is going to using a POST request but is not going to be sending the info exactly how the Services Rest Server is expecting. In a hook_init function I change the $_POST variable to what the Rest Server expects(rename the parameter "account") .

So after my hook_init the $_POST variable is exactly as the Rest Server wants it. The problem is that when it gets to "parseRequest" the current code doesn't recognise it as a POST request b/c of the reason I specified in #1.

It then falls through the switch case and gets the input by reading the raw input stream. Of course my hook_init method didn't affect the this input like it did the $_POST variable.

The problem I see with the current code is that it appears when first looking at the code that if a POST's content type is "application/x-www-form-urlencoded" then it will use the $_POST variable for $data. In fact though if $_SERVER['CONTENT_TYPE'] has any valid parameters it will not use the the $_POST variable but rather the raw input stream.

The core of the problem is when I rely on what I believe to be the intention of the code, i.e., If the post is a "form-urlencoded" then it will use the $_POST this doesn't work.

One way around this would be adding the ability to alter what is parsed from the request. Something like this:

  private function getControllerArguments($controller, $path, $method, &$sources=array()) {
    // Get argument sources
    $parameters = $_GET;
    if (isset($parameters['_method'])) {
      unset($parameters['_method']);
    }

    $data = $this->parseRequest($method, $controller);
    drupal_alter('rest_parsed_request',$data);

Sorry to be so long winded.

@voxpelli et all,

I have attached the patch with change requested in #6.

Here is the example of how I am using the alter in my case

/**
 * Implements hook_rest_server_request_parsed_alter().
 */
function modulename_rest_server_request_parsed_alter(&$data, $context){
  $callback = $context['controller']['callback'];
  if($callback == '_user_resource_create'){
    $data['account'] = $data;
  }
}

I don't like the fact that I have to check the callback to determine where I am at. It would nice if I could check for the resource, "user" and the operation, "create" but this not available in the controller object at that point, correct? I also don't think there is anything else that should be sent in the context but maybe there is.

Reading the docs for drupal_alter here: http://api.drupal.org/api/drupal/includes--module.inc/function/drupal_al...
It says:

If it is absolutely required that no implementation alters a passed object in $context, then an object needs to be cloned

I was wondering if I should clone the $controller variable so it cannot get altered but don't know if it is worth the performance hit that the clone call would add. Any thoughts?

Sorry attached incomplete patch file. Please regard #7's patch.

Also this patch I changed the way the $controller is being passed so the implementation would be

/**
* Implements hook_rest_server_request_parsed_alter().
*/
function modulename_rest_server_request_parsed_alter(&$data, $controller){
  $callback = $controller['callback'];
  if($callback == '_user_resource_create'){
    $data['account'] = $data;
  }
}

@voxpelli thanks for catching that