On Fri, Feb 7, 2014 at 1:44 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> [...]
> It is really awkward.
> Many applications use HTTP and HTTPS interchangably in the same application
> and I think it would be unfortunate to push these applications into having
> to set different options depending on which specific protocol they use.
> [...]

Indeed, my own application does exactly that. But I don't think that
the level of "awkwardness" is a major problem here. If one sets
headers manually, then one probably needs full control: i.e. the
ability to send headers exactly as specified (in an unchanged order,
case, and without intrusion of any default headers set by the
library/tool), and the ability to control where they are sent. I don't
think that it matters that much whether HTTPHEADER or PROXYHEADER is
used to achieve this goal, or both. So while your third proposal
sounds the most sensible from the usability point of view (though not
necessary from the point of implementation simplicity), it would be no
different for me that the other two, because mixing of HTTPHEADER and
PROXYHEADER for non-tunnelled proxying would likely result in headers
being sent in a wrong order. So I would likely select one of
HTTPHEADER or PROXYHEADER and use it exclusively. (Yes, I know that in
theory the order of headers is not significant, but... If servers I am
talking to were fully HTTP-compliant, I would not need to set any
headers manually in the first place.)

So I'd say go with the third one (as below), if it is not too
difficult to implement.

> "If CURLHEADER_SEPARATE is set, headers intended for a HTTP proxy must be
> set with the CURLOPT_PROXYHEADER option and headers intended for the remote
> host must be set with CURLOPT_HTTPHEADER."
>
> If using normal HTTP with a proxy, both lists are used in the same single
> request. If using HTTPS, they're used separately. If using HTTP(S) without a
> proxy, the proxy list is not used at all.

Thanks
Maciej
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-02-10