curl-library
SMTP: compatibility concerns with bug #1389
Date: Tue, 19 Aug 2014 13:50:15 -0500
Hello all,
[I'm a first-time poster; please correct me if I inadvertently break
mailing list etiquette.]
We're in the middle of a large libcurl upgrade (7.26 to 7.37.1) and we
ran into bug #1389 [1]: after cURL 7.34, CURLOPT_UPLOAD is now required
when using SMTP to send mail. Unfortunately we have libcurl clients in
the wild that relied on the old behavior -- they did not set
CURLOPT_UPLOAD -- and while it would be _possible_ to upgrade all of
them, it would also be prohibitively expensive. So I have two questions:
1) Can anyone provide guidance on how we might safely revert this
behavior in our copy of 7.37.1? We can develop a patchset ourselves,
certainly, but I'm hoping to get a starting point so that we don't
introduce other bugs or go in completely the wrong direction.
2) Does libcurl have a policy on behavioral compatibility? From what I
can tell from the previous conversations [2] on the topic, the official
statement seems to be that any SMTP client that wasn't setting
CURLOPT_UPLOAD was buggy. I'm fine with that, if that's the answer (and
we'll be adding CURLOPT_UPLOAD to our new client code). But as someone
looking in from the outside, it seems like it was sort of a retroactive
decision -- especially since the libcurl SMTP examples didn't have it
either.
Put another way: How do I ensure that our current libcurl client code
(HTTP, SMTP, or otherwise) does not contain other bugs of this nature,
so that we won't break in the future because of a missing CURLOPT?
[1] http://sourceforge.net/p/curl/bugs/1389/
[2] http://curl.haxx.se/mail/lib-2013-12/0154.html
Thanks very much for your time!
Jacob Champion
LabVIEW R&D
National Instruments
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-08-19