Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

curl_easy_escape used to accept empty string arguments, now returns error code #5601

Closed
kristofg opened this issue Jun 24, 2020 · 2 comments
Closed

Comments

@kristofg
Copy link

I did this

We have this code adding proxy username and password to a request:

        char * esc_user = curl_easy_escape(curl_handle, getProxyUser().c_str(), 0);
        char * esc_pwd = curl_easy_escape(curl_handle, getProxyPassword().c_str(), 0);
        if (esc_user && esc_pwd) {
            std::ostringstream s;
            s << esc_user << ":" << esc_pwd;
            curl_easy_setopt(curl_handle, CURLOPT_PROXYUSERPWD, s.str().c_str());
        }
        else {
            if (!esc_user) {
                // warn
            }
            if (!esc_pwd) {
                // warn
            }
        }
        curl_free(esc_user);
        curl_free(esc_pwd);

I expected the following

Up to and including curl 7.70.0, the code above has produced the expected output, also for empty passwords.

After upgrading to 7.71.0, this code warns about failure to escape the proxy passwords in a test case where getProxyPassword()returns an empty string, "".

I suspect this has to do with the changes to lib/escape.c done in this commit. DYNBUF.md says it Returns a char * to the buffer if it has a length, otherwise a NULL. . If I understand this correctly, this means an empty string passed into curl_easy_escape() will now return an error (NULL) instead of a pointer to an empty string buffer.

This is easy enough to work around, by checking for string emptiness before calling curl_easy_escape(), but is it intentional?

curl/libcurl version

7.71.0

operating system

Linux

@bagder
Copy link
Member

bagder commented Jun 24, 2020

No, it was not intentional. The change of internal representation should not effect the public API. I consider this a bug.

bagder added a commit that referenced this issue Jun 24, 2020
Regression added in 7.71.0.

Fixes #5601
Reported-by: Kristoffer Gleditsch
bagder added a commit that referenced this issue Jun 24, 2020
@bagder bagder closed this as completed in 32defc3 Jun 24, 2020
bagder added a commit that referenced this issue Jun 24, 2020
@kristofg
Copy link
Author

That was quick - thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants