Allow transformRequest to modify headers

[remcohaszing]

In AngularJS 1.4.0-beta5 the possibility to modify request headers from transformRequest functions has been removed. This is stated in the changelog. I found this a very useful feature to modify the Content-Type of the request being made.

For example:

$http.post('', {
  foo: 'bar'
}, {
  transformRequest: function(data, headers) {
    headers()['Content-Type'] = 'application/x-www-form-urlencoded';
    var parsed = [];
    angular.forEach(data, function(value, key) {
      parsed.push(encodeURIComponent(key) + '=' + encodeURIComponent(value));
    });
    return parsed.join('&');
  }
});

I often use a similar approach to make form-data requests, which requires the Content-Type to be set to undefined.

In practice I have created an xWwwFormUrlencoded and formData factory, because I use them more often.

So the code would look like this:

$http.post('', {
  foo: 'bar'
}, {
  transformRequest: xWwwFormUrlencoded
});

It feels like a huge drawback having to to explicitly specify the headers whenever making such a transformed request.

The following plunkr demonstrates this issue. The test breaks when updating AngularJS to 1.4.0.

[Narretz]

Hmm. I can see how this in inconvenient. There are basically two ways

• setting headers explicitly
• using an interceptor (but you have to filter the requests to which they should apply)

However, if you have a factory for the transformRequest, couldn't you simply do:

$http.post('', {
  foo: 'bar'
}, {
  headers: xWwwFormUrlencoded()
});

[pkozlowski-opensource]

Yeh, I can see how this is inconvenient and while interceptors work they add overhead of the async processing. having said this I really dislike APIs where input arguments are getting modified....

Maybe we should make it possible to return both transformed data and headers from the transform request function?

[Narretz]

The headers property could also accept a function that gets passed the current config + default headers and is expected to return a headers object.

[remcohaszing]

Actually using an interceptor sounds like a perfect solution in my case. I could just filter out requests which specify an x-www-form-urlencoded content type and modify the body accordingly.

If the function would be able to return both the transformed data and headers, I imagine this would return an array consisting of [data, headers]. This seems like a bad idea to me, because developers may want to return an array as data.

If the headers would accept a function for transforming the headers, this means that a modifications to body according to the content type would happen in the headers function as well.

Another option could be that transformRequest accepts either a function or an object. If a function is passed, it behaves the way it normally does.
If an object is passed, it may define a function for transforming the body and a function for transforming headers.

$http.post('', {
  foo: 'bar'
}, {
  transformRequest: {
    body: function(data, headersGetter) {
      return myTransformFn(data);
    },
    headers: function(data, headersGetter) {
      var headers = headersGetter();
      headers['Content-Type'] = 'x-www-form-urlencoded';
      return headers;
    }
  }
});

[pkozlowski-opensource]

I imagine this would return an array consisting of [data, headers]. This seems like a bad idea to me, because developers may want to return an array as data.

There are many ways to solve it cleanly, ex.: returning an instance of a specific class. So I don't think we are blocked from applying this solution, implementation-wise.

[LeleDev]

I was using this feature too...

It's really important to me the ability to change headers in the transform request, instead of in every single function... please bring this feature back if possible...

[zalos]

Agreed, we now have to find a work around while updating.

[vellotis]

+1 👍
I somehow have to set "X-HTTP-Method-Override", which I can't do at the moment.

[wmfairuz]

Any workaround on this issue?

[Narretz]

@wmfairuz yes, interceptors

[gkalpak]

Since there is a "work around" for now and considering ngResource interceptors/transforms will probably/hopefully change soon (as discussed in #9334, #11409, #13273), I'm going to close this.

Specifically, this should be fixed by #13273. Let's track it there.