This is an issue if you are trying to simulate the actual behavior of a
browser. People, for instance, writing a click-fraud script would find
this problematic. OTOH, certain people, detecting people writing scripts
to perpetrate click-fraud, are quite happy about this :)

Daniel Stenberg wrote:

> On Tue, 11 Oct 2005, Roberto Nibali wrote:
>
>> Which is not at all the order I submitted my headers. What's the
>> reason for this behaviour? What am I doing wrong or what did I forget
>> to read?
>
>
> 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.
>
> 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.
>
> 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.
>
> Are you suffering from any problems due to this or are you just curious?
>
Received on 2005-10-11