Headers removed when using request_serializer :json

[mariochavez]

Hi,

I need to post to a service that expect body to be in json format but also this service expect headers like:

• 'Content-type', 'application/json'
• 'Accept', 'application/vnd.service-v0.1+json'
• 'Authorization', "Basic #{key}"

If I don't use the request_serializer :json my service receive the headers but content is not send as json, if I add request_serializer :json content is sent as json but headers are missing.

    AFMotion::Client.build('http://127.0.0.1:4567') do
      header 'Content-type', 'application/json'
      header 'Accept', 'application/vnd.service=v0.1+json'
      header 'Authorization', "Basic #{key}"

      #request_serializer :json
      response_serializer :json
   end

I'm not sure what I'm missing here, if this is the right behavior or if this is a bug.

[mariochavez]

Never mind seems that calling request_serializer :json removes headers but if I call it before setting my headers everything just works.

[zmillman]

I just got bitten by this behavior 😡

Not at all what was expected and it goes completely against everything documented in the README.

[zmillman]

Could we re-open this issue until either a fix is implemented or the documentation has been updated?

[clayallsopp]

@zmillman I'd happily accept a PR which changes the README - I'm not sure if this is a bug or not (I don't recall the default behavior when doing the same with vanilla AFNetworking), but if you do want to investigate more I'd definitely merge that PR as well

[zmillman]

Seems like issue is that request_serializer in AFMotion::ClientDSL initializes a new serializer which doesn't retain any of the configuration of the serializer it's replacing which was set up earlier in the clobk.

In Obj-C, you have to be very explicit about which serializer you're configuring headers for so you wouldn't even be able to call the equivalent of header until after you called the equivalent of request_serializer. It's surprising as a developer that the client DSL is not order-agnostic, and the examples in the README are the reverse of proper configuration.

I'm not sure whether order mattering in the DSL is truly a "bug" (or just a vicious gotcha) but I'll definitely throw together a PR to clarify the documentation.