When @mpeylo submitted his CMP implementation to OpenSSL a couple of years back he got the feedback that it should not use libCURL but OpenSSL's own HTTP client, which so far is used mainly for fetching OCSP responses (but also CRLs and certificates) .
So we changed CMPforOpenSSL to make use of the implementation in crypto/ocsp/ocsp_ht.c.

Unfortunately this HTTP client is tailored for use with OCSP and is very primitive - in particular, handling of delayed responses and errors is very poor and there is no support for more advanced features such redirection and use of proxies.

One of the next chunks of our current CMP contribution contains the HTTP client to be used for CMP, which will reside in crypto/cmp/cmp_http.c. The current state of its development can be found in https://github.com/mpeylo/cmpossl/blob/cmp-dev/crypto/cmp/cmp_http.c
This implementation is based on the mentioned HTTP code in ocsp_ht.c, while it contains improvements for those of its shortcomings critical for CMP: it

• can send and receive any types of ASN.1-formatted requests and responses
• does not include a potentially busy loop when waiting for responses
  but makes use of timeout mechanism integrated with socket-based BIO
• returns more useful diagnostics in various error situations
• supports the use of HTTP proxies and of TLS (including TLS over proxies)

I've already shaped the code in cmp_http.c such that several portions of it could more or less directly generalize and improve the existing HTTP client code in ocsp_ht.c, apps/ocsp.c, apps/s_client.c, and apps/lib/apps.c.

What is your view on these improvements - should I push them upstream (as a couple of independent PRs) for general use or should we keep them in cmp_http.c?