On Fri, Feb 7, 2014 at 1:44 AM, Daniel Stenberg <dan...@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
