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: Bug(?): problem with imap fetch CURLOPT_CUSTOMREQUEST
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Ray Satiro via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 23 Jun 2022 00:20:42 -0400
On 6/15/2022 7:38 AM, Adrian Lewandowski via curl-library wrote:
> When sending the following custom request to imap server:
>
> curl_easy_setopt(curl, CURLOPT_CUSTOMREQUEST,
> "fetch 1 rfc822"
> );
>
> libcurl yields unexpected results producing simply
> * 1 FETCH (RFC822 {764347}
> This applies to both, the default setup that prints to stdout, as well
> as to
> a program with registered custom CURLOPT_WRITEFUNCTION handler.
> In the latter case, however, we can investigate the internal curl buffer,
> passed as the first argument to the handler BEYOND the number of bytes
> passed
> to the handler in the other parameters (even though it is technically
> UB).
> And it turns out, that the information that is supposed to be returned
> by FETCH
> seems to be there, but for some reason libcurl chooses to discard it.
>
> I'm aware that this 'bug' was previously reported here :
> https://github.com/curl/curl/issues/2055
> with conclusion "This does not appear to be a bug in curl",
> perhaps because of the lack of communication with the guy who reported
> it.
> I also realise that (according to this link) there are alternative ways
> of retrieving this information, which may be better than direct FETCH.
>
> However, it does certainly seems to be a bug, or at least highly
> unexpected behavior -- the information that is supposed to be produced
> be FETCH is in the buffer -- simply libcurl does not want to disclose
> it for some misterious reason. In any case, if custom request are
> supported, they should produce what they are supposed to [BTW, I
> really love libcurl, even though I'm just starting to use it,
> otherwise I would not bother to report this bug].
>
> I'm on Ubuntu 20.04, using libcurl shipped with my distro, and g++ as
> a compiler;
> curl_version() yields:
>
> libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0
> libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib
> nghttp2/1.40.0 librtmp/2.3
>
> A c++ file wich shows the problem is in the attachment -- simply
> switch between
> writeCallback and writeCallback_UB (the latter gives what I need).
As I said in that issue "If you use CURLOPT_CUSTOMREQUEST then in most
imap cases curl will not parse the data out to a body because it is a
custom request. So in those cases the data remains part of the header.
You would have to use CURLOPT_HEADERFUNCTION." [1]
Do not attempt to access the data from the write function by reading
past the length given.
I'm not against proposed improvements to this situation I just don't
think it's a bug, libcurl is behaving as intended.
[1]: https://github.com/curl/curl/issues/2055#issuecomment-342399890
Date: Thu, 23 Jun 2022 00:20:42 -0400
On 6/15/2022 7:38 AM, Adrian Lewandowski via curl-library wrote:
> When sending the following custom request to imap server:
>
> curl_easy_setopt(curl, CURLOPT_CUSTOMREQUEST,
> "fetch 1 rfc822"
> );
>
> libcurl yields unexpected results producing simply
> * 1 FETCH (RFC822 {764347}
> This applies to both, the default setup that prints to stdout, as well
> as to
> a program with registered custom CURLOPT_WRITEFUNCTION handler.
> In the latter case, however, we can investigate the internal curl buffer,
> passed as the first argument to the handler BEYOND the number of bytes
> passed
> to the handler in the other parameters (even though it is technically
> UB).
> And it turns out, that the information that is supposed to be returned
> by FETCH
> seems to be there, but for some reason libcurl chooses to discard it.
>
> I'm aware that this 'bug' was previously reported here :
> https://github.com/curl/curl/issues/2055
> with conclusion "This does not appear to be a bug in curl",
> perhaps because of the lack of communication with the guy who reported
> it.
> I also realise that (according to this link) there are alternative ways
> of retrieving this information, which may be better than direct FETCH.
>
> However, it does certainly seems to be a bug, or at least highly
> unexpected behavior -- the information that is supposed to be produced
> be FETCH is in the buffer -- simply libcurl does not want to disclose
> it for some misterious reason. In any case, if custom request are
> supported, they should produce what they are supposed to [BTW, I
> really love libcurl, even though I'm just starting to use it,
> otherwise I would not bother to report this bug].
>
> I'm on Ubuntu 20.04, using libcurl shipped with my distro, and g++ as
> a compiler;
> curl_version() yields:
>
> libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0
> libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib
> nghttp2/1.40.0 librtmp/2.3
>
> A c++ file wich shows the problem is in the attachment -- simply
> switch between
> writeCallback and writeCallback_UB (the latter gives what I need).
As I said in that issue "If you use CURLOPT_CUSTOMREQUEST then in most
imap cases curl will not parse the data out to a body because it is a
custom request. So in those cases the data remains part of the header.
You would have to use CURLOPT_HEADERFUNCTION." [1]
Do not attempt to access the data from the write function by reading
past the length given.
I'm not against proposed improvements to this situation I just don't
think it's a bug, libcurl is behaving as intended.
[1]: https://github.com/curl/curl/issues/2055#issuecomment-342399890
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-06-23