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: 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