Thanks for the suggestion, that helped me find the real issue.
There was a newline at the end of the URL.
Both the WinInet and Mac Framework let it through but cURL caught it.
Best,
Bob
On 3/6/20 7:40 PM, Jeffrey Walton via curl-library wrote:
On Fri, Mar 6, 2020 at 6:08 PM Robert Brose via curl-library
<curl-library@cool.haxx.se> wrote:
I'm having trouble figuring out what I'm doing wrong with an
implementation of libcurl that is working for everything else I can
throw at it. I've done a lot of searching stack overflow, etc and
haven't figured out the issue yet.
Using the latest libcurl I'm getting the above error back immediately
with no data sent. It looks fine as far as I can tell and if I put the
same URL into command line curl it works fine.
https://r3---sn-vgqs7nlk.googlevideo.com/videoplayback?expire=1583550131&ei=U7piXujKIseCir4PhKec-Aw&ip=1.1.1.1&id=o-AHAFYbXI8YRoD0acpA-MVWR0l6dylcQoX4c-r7Jx4vMg&itag=248&aitags=133%2C134%2C135%2C136%2C137%2C160%2C242%2C243%2C244%2C247%2C248%2C278&source=youtube&requiressl=yes&mm=31%2C26&mn=sn-vgqs7nlk%2Csn-qxoedn7d&ms=au%2Conr&mv=m&mvi=2&pl=20&initcwndbps=805000&vprv=1&mime=video%2Fwebm&gir=yes&clen=84511680&dur=357.123&lmt=1583350521559494&mt=1583528433&fvip=3&keepalive=yes&fexp=23842630&c=WEB&txp=5431432&sparams=expire%2Cei%2Cip%2Cid%2Caitags%2Csource%2Crequiressl%2Cvprv%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt&sig=ADKhkGMwRQIgCzr9srMO-3hlIOxxHI3EhMcB63reuEgfYcupN8315joCIQC315T8NyWNZv0oTedYBMepYi3ParbWUYp1Rgv_trMAsA%3D%3D&lsparams=mm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=ABSNjpQwRQIhAKo-wN50dUGo82aZ83P1PeleKiM_Whxp4HGrSd5w37hWAiAhVmYKbyqzmUGspMejmVGLWwbet8j3Z2nv8shJ3bF4Gg%3D%3D&ratebypass=yes
It's a GET so I'm just using this to set it up:
curl_easy_setopt(m_cURLFile->handle.curl, CURLOPT_URL,
JRStringUTF8(m_fnURL.GetFilename()).GetString());
The JRStringUTF8(m_fnURL.GetFilename()).GetString() returns a pointer to
the null terminated c string exactly as seen above.
All of the rest of the curl setup is precisely how I'm doing it for
every other GET request.
I run it through URL validators and it's fine.
Is there some sort of maximum URL length?
If curl is not making a copy of JRStringUTF8, then the string could be
going away before the command completes.
Maybe you can add a first class temporary object that holds the
string. Then use it like:
char* temp = new char [...];
copy_string(temp, ...); // copy JRStringUTF8
curl_easy_setopt(m_cURLFile->handle.curl, CURLOPT_URL, temp);
delete[] temp;
The code above tries to rule out early destruction of the string, but
it is just a guess. It would probably be helpful if you could provide
more context. Is the code available on GitHub?
Jeff
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
