> The reasons for the order you see is really two-fold:
>
> 1) According to the HTTP specs, the order of the headers are not
> important so
> you should not suffer from any problems because in what order libcurl
> would
> send them in.

Valid point.

> 2) The ordering is quite simply sent in the order of the code flow. libcurl
> creates its set of header in a fixed order, and if you replace a
> built-in
> header it will use your replaced content instead of the original content
> but in the same spot in the header. When it has added all the internal
> headers (replaced or not) it adds the added headers that didn't
> replace any
> internal ones.

So what's the order of the internal headers? Also might it be possible
that if you don't overwrite an internal header that it is not even sent?

> Those reasons aside, libcurl doesn't keep track of what order you set
> most libcurl options in, so if you set for example CURLOPT_ENCODING and
> CURLOPT_REFERER, it will always send those headers in the same fixed
> order with no regard in what order you set them in.

I would like to document this. However the order of appearance of those
header options was not apparent to me from glancing over your code in 10
minutes ;).

> Are you suffering from any problems due to this or are you just curious?

Insomnia :). No, not really, but I tend to really double-check what my
code does and the fingerprint of the http header I sent did not match
the fingerprint on the receiving end and this raised an alarm in the IDS
when the monitoring tried to match the expected header output with the
configured input.

Other than that all is fine. Regards,
Roberto Nibali, ratz

-- 
-------------------------------------------------------------
addr://Kasinostrasse 30, CH-5001 Aarau tel://++41 62 823 9355
http://www.terreactive.com             fax://++41 62 823 9356
-------------------------------------------------------------
terreActive AG                       Wir sichern Ihren Erfolg
-------------------------------------------------------------