Re: Bug(?): problem with imap fetch CURLOPT_CUSTOMREQUEST

From: Adrian Lewandowski via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 23 Jun 2022 18:25:36 +0200

Ray,
That indeed works (I somehow missed that part of your answer).
Many thanks that you bothered to answer my question/unjustified bug report.

While some improvement in that are would be nice, I just really wanted to
know what is the correct way of getting the data (without invoking UB).

Best wishes,
Adrian




czw., 23 cze 2022 o 06:21 Ray Satiro via curl-library <
curl-library_at_lists.haxx.se> napisał(a):

> 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.html
>

-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2022-06-23