curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Strange connection persistence problem

From: Timothe Litt <litt_at_acm.org>
Date: Thu, 30 Nov 2023 12:34:12 -0500

You really need to provide a reproducer - as simple as possible.

That said: is _URL a #define constant or a variable?  Your printf
doesn't have a \n - if you're seeing one, perhaps _URL has a \n - which
can confuse things when it's inserted into the headers (makes the
headers end early).  I recommend using "'%s'\n" in these situations -
this ensures that an whitespace is obvious. (That's " ' %s'  \n " but
without the spaces.)

What "doesn't work" about the setopt?  Does it return an error code, or
just not do what you expect?  If an error code (and you should always
check), what is it?

To see if it's an optimization issue, try -O0 (or the equivalent).   
Does printf after the setopt return the same value as before (it should,
I believe curllib always copies the input string.

Compilers do make mistakes, but 99.9% of the time it's something you're
doing wrong.

If you're passing the _URL to other routines, make sure you're not
violating C's aliasing rules.

Make sure you haven't free()'d _URL before the setopt call - its malloc
could re-use the block in that case.

Run with valgrind (or equivalent) to find most issues of this sort.

Actually, including a \n in inputs is common enough that perhaps curllib
should check for it (at least with debug enabled) and return an error...

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

On 30-Nov-23 12:00, Max via curl-library wrote:
> Thank you Daniel.
>
> I am using libcurl-7.85.0-12.fc37.x86_64
>
> It is odd that if I do (down in my code) one after the other:
>  printf("%s",_URL);
>  curl_easy_setopt(curl, CURLOPT_URL, _URL);
>  ...
> then printf outputs the correct url content but the following
> curl_easy_setopt does not work.
>
> I noticed that due to some compiler optimization _URL although changed
> in content is kept starting at the same initial memory address.
>
> Moreover, if you have noticed, the header Host field is correct but the
> GET location is not.
>
> Are you checking the _URL memory address (pointer) somewhere in the
> library code developing curl_easy_setopt(curl, CURLOPT_URL, _URL)?
>
> Maybe there is some kind of optimization based on the memory address
> of _URL.
>
> I have no better ideas!
>
> Thanks for any clue.
>
>
>
>
>
> On 11/30/23 16:21, Daniel Stenberg wrote:
>> On Thu, 30 Nov 2023, Max via curl-library wrote:
>>
>>> The following (problematic) step is
>>> GET https://desthost.com/home/landed
>>> *   Trying NNN.NNN.NNN.191:443...      <<< mapped to different IP
>>> * Connected to desthost.com (NNN.NNN.NNN.191) port 443 (#3)
>>> ...
>>>> GET  /v1/pub/auth/web/login?scd=true HTTP/1.1
>>> Host: desthost.com
>>>
>>> How comes my GET goes to the previous URL (that of the POST) and not
>>> my new URL?
>>
>> Wow. That certainly looks wrong and I have no explanations as to why
>> or how that can happen. I have never seen anything like that.
>>
>> This is going to be really hard to do anything about without an
>> example code that can reproduce the symptoms. If you write something
>> basic doing the same logical set of requests + methods in a similar
>> series, can you make the problem happen?
>>
>> Is this using a modern libcurl version?
>>

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
Received on 2023-11-30