I no longer need this hack, however, there might be situations you need to override host header (proxy use etc) so might still make sense to support

Perhaps the client should allowaddHeader to overrideHost:?
Meaning, when headers are prepared it would check whether it was added or not; and if not, use the default_host. Right now it is restricted, don't see why it should be tbh

@mcspr I suppose, however to be completely http compliant, you can pass multiple values for same header, most other http implementations do setHeader and addHeader, where setHeader sets a single header and replaces whatever would have been there before, and addHeader would send multiple values.

However in this case, judging by the code I suspect the restriction here is to kep the code simple as the host header is hardcoded in the request call.

I would be fine rejecting this PR as I no longer need it, but possible it could make sense to consider adopting more http client features in the future, if needed... I suspect for most applications using these microchips, explicit proxy settings etc is overkill so I personally would consider it a corner case