-K/--config does not work correctly with the --next option #5120
The handling of the linked list of
As an alternative to (2) and (3), consideration should be given to making the
Below, you'll find some tests.
I did this
First, I set up a simple HTTP server which echos back the request and any headers starting
Invoking curl using command-line arguments works as expected:
But when the -K option is used, these fail in various ways.
If all of the request are in config files, then only the first and the last are processed. (The second and third are successively overwritten as described above.)
Other failure modes occur when config files are mixed with requests on the command line, because the OperationConfig being filled in by
This can also result in options at the end of the command line being applied in surprising ways in certain circumstances, if not preceded on the command-line with
I expected the following
I expected all of the four-request command lines above to produce exactly the same output, and for the "surprise" headers to be added to the last config-file, not the first one. (Had the first request been a command-line request, these headers would have been added to it rather than the config-file request. That might be considered less surprising, but it's still surprising.)
and also with the latest tarball
But I think the behaviour dates back to this commit in early 2014: fc59a9e
But it's probably cross-platform.
The text was updated successfully, but these errors were encountered:
By the way, this bug report falls out of trying to answer a question on StackOverflow.
As an additional test, as indicated in my answer to that question, I had attempted to hoist the
Ensures that -K/--config inserts new items at the end of the list instead of overwriting the second item, and that after a -K/--config option has been parsed, the option parser's view of the current config is update. Fixes curl#5120