allow per-message soap headers

[cout]

I thought I had already entered this bug report/feature request, but I don't see it now, so I'm entering it again.

We need to be able to add additional soap headers per-message for WS-Addressing (each message needs its own message id, which afaict goes in the soap header). Currently we are using the following:

# The Savon client by default does not allow adding new soap headers
# except via the global configuration.  This monkey patch allows adding
# soap headers via local (per-message) configuration.
module Savon
  class LocalOptions < Options
    def soap_header(header)
      @options[:soap_header] = header
    end
  end

  class Header
    def header
      @header ||= build_header
    end

    def build_header
      header = {}
      header.update(@globals.include?(:soap_header) ? @globals[:soap_header] : {})
      header.update(@locals.include?(:soap_header) ? @locals[:soap_header] : {})
      return header
    end
  end
end

This allows the soap_header option to be used globally or locally.

[kenberland]

+1

[rubiii]

ok, so how would you expect savon to work when someone uses a global and local soap_header option?
as far as i can see, we would need to either deep merge both hashes or prefer the local over the global hash.

i'm not really sure if it makes sense to keep the global option at all. it might be a little more tedious for people who always send the same header, but everything can be automated and if you properly abstract external libraries, it should be easy to update your abstraction.

what do you think?

ps. of course we would need to implement some solution, deprecate the global option and remove it in a future 2.x release to give people time to upgrade.

[cout]

I would expect a shallow merge (which is what I implemented).

I did not consider a deep merge. A deep merge would make it more difficult to override an entire subtree, but would allow overriding individual leaf nodes.

I don't know which is preferable, because I don't know what typical use cases would be. Any of the options (shallow merge, deep merge, local completely overriding global, and completely eliminating global) would work for what I want to do.

I suspect users would be most likely to use either local or global and not both. A deep merge is probably unnecessarily complex.

Eliminating global might break existing code for a very small benefit.

[rubiii]

thanks. the shallow merge sounds fine to me. removing the global option really doesn't make things easier.
i just searched through issues and pull requests but couldn't find the original issue you mentioned.
would you be able to open a pull request for this?

[cout]

I can. I didn't do the change as part of a branch, just did the monkey patch. I can have a real patch and pull request some time tomorrow.

[rubiii]

great! thank you.