Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
curl: allow --header and --proxy-header read from file #1486
I don't know what he's talking about with the securing curlrc, if he uses --config foo it's still going to read the default curlrc. I will follow up on that on the list. So a change for this isn't necessary. Also this is breaking due to lack of strtok_r in Windows CI. strtok.h is only in the library so that would need to be changed or you could just use strtok and add a comment overidding checksrc and saying allow strtok since not threaded
Thanks for the quick work. Sorry I missed that --config doesn't supersede the user's
One comment on the code - you do an fopen with mode 'rb'. 'b' is binary (on systems that care). This is text input. So you probably want 'r'... you can't count on in the file for building the header; it might be there; might not; might be before the or after. Or you might get record length bytes... or untranslated wide chars.
I don't see that as a safe bet at all. If you would save regular incoming received HTTP headers in a file, they are CRLF separated, and if you then use such a file as input to this on a *nix... I think it is safest to check for both. Updated version coming up...
I'm not sure I agree. Why would
I edited the wording for
We tried that in the past and it turns out really hard and more confusing than this. Most options are related to at least a few others so in which order should they come, really?
Well, that's a question of where the bug is. Both the network and filesystems have defined rules, and
I'd argue that whomever is saving headers to a text file should be removing the network-required CR,LF and writing to a text file with \n. That's portable. \n is defined to be "whatever the target filesystem wants"; CRLF; CR; LFCR; LF; or even (control-word, data). Headers are network ASCII.
Of course, the file should have been opened with "w", not "wb". Then the C RTL won't add CR when it's written. Except on a CRLF file system. Opening that file with 'r' will always yield \n -- even on a CRLF system, where the C RTL will remove the CR. (And \n isn't always 012...)
When you play by the rules, what's written will always be correct for native utilities - e.g. diff, your favorite editor, etc.
You can be tolerant of stray on input from files - but definitely should not be reading and writing text files with 'b' and '\n'. You must of course, deal with network ASCII by it's rules - emit , be tolerant of bare , and use \012 for LF - not '\n'. (On some systems, \n is 015 - and odder things. )
In any case, I appreciate your work. It's rare to see such a quick response.
Bug: #1486 (comment) Reported-by: Dan Fandrich