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: CURL_FTP_HTTPSTYLE_HEAD
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 18 Jan 2024 13:43:23 -0800
On Wed, Jan 17, 2024 at 03:28:11PM +0100, Nejc Drašček via curl-library wrote:
> I'm using ftp library ( github.com/embeddedmz/ftpclient-cpp ), which under
> the hood uses libcurl, and some requests are "polluting" stdout with http
> headers:
>
> Last-Modified: Mon, 15 Jan 2024 14:32:44 GMT
> Content-Length: 0
> Accept-ranges: bytes
>
> According to comment in lib/ftp.c this define is/was supposed to be removed
> at next so bump. The define is still enabled on master at the time of this
> message. Modifying libcurl source locally is not an option since we're using
> vcpkg to manage (external) libraries.
>
> If there is a way to do this I would be much obliged to be pointed in that
> direction.
I zoomed right over the identifier in the subject and didn't see it. Those
#ifdefs were added 17 years ago, and given curl's goal of backward
compatibility and no SONAME bumps, it's unlikely to be removed in the next 17
years.
Having said that, this codes writes to the write function so what happens to it is
under the application's control. If an application doesn't want it written to
stdout, it shouldn't write it to stdout. But, if the application is performing
a NOBODY request over FTP, presumably it wants to get some metadata for that
URL and therefore some output. In this respect, ftp: is handled the same as
http: support in this respect. Both:
curl -I ftp://mirror2.tuxinator.org/robots.txt
and
curl -I https://www.tuxinator.org/robots.txt
return similar kinds of information in similar ways.
I don't know what ftpclient-cpp does or wants to do with these requests, but it
sounds like it's not doing them in the way you want or expect. That's more
likely to be a problem with it rather than with curl.
Dan
Date: Thu, 18 Jan 2024 13:43:23 -0800
On Wed, Jan 17, 2024 at 03:28:11PM +0100, Nejc Drašček via curl-library wrote:
> I'm using ftp library ( github.com/embeddedmz/ftpclient-cpp ), which under
> the hood uses libcurl, and some requests are "polluting" stdout with http
> headers:
>
> Last-Modified: Mon, 15 Jan 2024 14:32:44 GMT
> Content-Length: 0
> Accept-ranges: bytes
>
> According to comment in lib/ftp.c this define is/was supposed to be removed
> at next so bump. The define is still enabled on master at the time of this
> message. Modifying libcurl source locally is not an option since we're using
> vcpkg to manage (external) libraries.
>
> If there is a way to do this I would be much obliged to be pointed in that
> direction.
I zoomed right over the identifier in the subject and didn't see it. Those
#ifdefs were added 17 years ago, and given curl's goal of backward
compatibility and no SONAME bumps, it's unlikely to be removed in the next 17
years.
Having said that, this codes writes to the write function so what happens to it is
under the application's control. If an application doesn't want it written to
stdout, it shouldn't write it to stdout. But, if the application is performing
a NOBODY request over FTP, presumably it wants to get some metadata for that
URL and therefore some output. In this respect, ftp: is handled the same as
http: support in this respect. Both:
curl -I ftp://mirror2.tuxinator.org/robots.txt
and
curl -I https://www.tuxinator.org/robots.txt
return similar kinds of information in similar ways.
I don't know what ftpclient-cpp does or wants to do with these requests, but it
sounds like it's not doing them in the way you want or expect. That's more
likely to be a problem with it rather than with curl.
Dan
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-01-18