2

I'm currently using curlpp to perform an HTTP query, but curlpp is reporting that there are illegal characters in the URL. I've narrowed down the URL problem to a variable that is being read from a config file (one line, it just contains the information needed). Another weird thing is that this only happens on a Fedora x64bits installation (I haven't tried other x64bits distros). On my two development machines it runs perfectly fine (Ubuntu and OpenSuse, 32bits). I've tried printing the ASCII code of the characters read from the file and everything looks perfectly normal, however, there is a line feed character at the end of the string. Now, this character occurs in all systems, but on the Fedora system it is reported as an illegal character. Replacing this character by the null termination character makes the program work perfectly again.

I was wondering if there is an option to force curlpp to ignore the line feed character. I’ve also tried escaping the string with the curl_easy_escape function, but it converts the line feed character to the percent encoding %0A. This, in turn, is not recognized by the HTTP server as an existing URL (it outputs a 404 error).

Has anyone encountered this issue before? Is it possible to ignore this character, or is the best approach just to replace it?

Thanks in advance for your help!

Best regards,

PS: In all systems, the library versions are the same (which is somewhat weird). The version of curlpp is (0.7.3)

EDIT: Due to popular demand, I'm posting the code that reads the variable from the file.

  std::ifstream keyfile (pathToFile.c_str());
  std::stringstream buffer;
  buffer << keyfile.rdbuf ();
user3124955
  • 63
  • 5
  • 1
    Share the code which reads value from conf file. Problem seems to be in your conf file or reading, not in Curl. – Nitinkumar Ambekar Jul 16 '15 at 10:21
  • 1
    The line feed character should not be part of the URL, I think you need to look at how the URL is being extracted from the config file - why is it reading the line-feed? – Galik Jul 16 '15 at 10:30
  • 1
    P.S. You could bodge it by trimming the string before using it: http://stackoverflow.com/a/25385766/3807729 but you really should fix the function that reads the config file. – Galik Jul 16 '15 at 10:38
  • I just added the code responsible for reading the file. It's not how I normally read a file in C++ (this is not my code, but a colleague's who has a ton more experience than I do). I googled the rdbuf function when I first encountered the problem, but couldn't see anything related to the LF character. Maybe you guys have some idea on why this happens... Thanks! – user3124955 Jul 16 '15 at 11:41
  • Does `buffer` now contain the `URL` and nothing else? Or is there more code to extract the `URL` from everything else that is in `buffer`? Basically how do you get the `URL` from `buffer`? – Galik Jul 16 '15 at 14:47
  • No, buffer now contains a portion of the URL. The portion that is causing the problem. In this case, it's an API key. buffer is then returned, as a string, by calling the buffer.str() function. If you print the ASCII code of buffer's characters it will show a bunch of characters (correctly) and, on the end, the LF code. – user3124955 Jul 16 '15 at 17:21

1 Answers1

0

The way you read the key file is going to dump everything into your std::stringstream including the end of line character.

One thing you can do is use >> which will read the first whole word it finds skipping leading spaces:

std::ifstream keyfile(pathToFile.c_str());
std::string api_key;

// will skip leading spaces and only read up to the next space
// or end of line
keyfile >> api_key;
Galik
  • 42,526
  • 3
  • 76
  • 100
  • First of all, I would like to thank you (@Galik) and @NTN for your huge help with this matter. Your answer fixed my issue, of course. I had a similar code (in functionality), which replaced the last char (str.length -1) with '\0', effectively removing the LF char. Now, I wanted to post two additional questions, if I may: Firstly, why do you think this happens only on one particular system, since the curlpp versions are the same? Secondly, why is rdbuff reading a LF when there isn't one? I mean, calling od -c on the file will output the key and a \n, nothing more. Thanks for your help – user3124955 Jul 16 '15 at 19:29
  • @user3124955 My guess would be on the other systems the data file simply did not have a trailing end-of-line character in them. Using `rdbuff()` reads the entire file in, so my guess would be that on some systems the api-key had been entered along with a new-line and on other systems it had been entered without the new-line. If that's not the issue, I have no idea :) – Galik Jul 16 '15 at 20:07