Weird problem with Content-Type headers / request type

[zetxek]

I need to invike a REST service that will output an answer only when the content-type of the request is form-data (specifically, "multipart/form-data") and the request type is POST. I have not full control of it.

I am trying to set the header and invoke with:

Map<String, String> params = new HashMap<String, String>(); HashMap<String, String> headers = new HashMap<String, String>();
params.put("nid", "21"); //I think it's irrelevant, but who knows headers.put("Content-type", "multipart/form-data"); NetworkEngine.getInstance().setUseCache(false); //to avoid any error due to cache or stuff like that NetworkOperation operation = NetworkEngine.getInstance().createOperationWithURLString("serviceUrl", params, HttpMethod.POST);
operation.addHeaders(headers); operation.addParams(params); //doing it twice, just in case
operation.setListener(LoginActivity.this); NetworkEngine.getInstance().enqueueOperation(operation);

The output by the server (404 service not found) makes me think that the request has not a right header or is not being executed as a POST Request, as it's the same output that I get on Chrome's Postman (https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm) when I invoke the service with a GET/PUT/DELETE request instead of a POST one.

By the way, with LoopJ's AsyncHTTPClient (http://loopj.com/android-async-http/) I get a right answer just by doing this:

AsyncHttpClient client = new AsyncHttpClient();
RequestParams params = new RequestParams(); params.put("nid", "21"); client.addHeader("Content-type", "multipart/form-data");
client.post("serviceUrl", params, new AsyncHttpResponseHandler() { @Override public void onSuccess(String response) { System.out.println(response); } @Override public void onFailure(Throwable t) { t.printStackTrace(); } }); }

Is there any step withing this library execution flow that may cause the headers being lost, or the request being invoked as get/put/delete instead of post?

[zetxek]

By the way, I could solve the issue with the request by enabling on the service admin panel the parsing of request with content type application/x-www-form-urlencoded, but anyway it could be useful knowing if there is any problem on setting custom content types...

And for adding more information about the issue, the REST service is published with a drupal services module (v 3.x, http://drupal.org/node/736522)

[netdev]

DroidNetworking currently doesn't support multipart/form-data. Even if you can set the Content-Type to multipart/form-data the request body in a POST or PUT request will be form-urlencoded. Your work around is correct if you would like to use the current version of DroidNetworking.

I'm planning to add support for multipart/form-data within the near future.

[zetxek]

Thanks for telling! In case of working on its support I'll make a pull request, let's see if I get time for it.