On Sat, Jun 14, 2014 at 11:16:11PM +0200, Daniel Stenberg wrote:
> colored output

We can take HTTPie [0] as model here (ignoring the evident bias towards
JSON-based HTTP APIs). The coloring of the HTTP headers is pretty neat [1], but
if I understand things correctly it would need to be implemented directly in
libcurl (I haven't looked into how to do it, but I could if there's interest).

[0] https://github.com/jakubroztocil/httpie
[1] https://raw.githubusercontent.com/jakubroztocil/httpie/master/httpie.png

> HTTPS: Live CRL checking and OCSP.

There's a wishlist bug about this in the Debian bts, and I have briefly looked
into how to implement OCSP (RFC2560) a while back. If I understand things
correctly there are 3 steps:

1. Generate OCSP request
2. Send OCSP request (via HTTP)
3. Check OCSP response

Both 1 and 3 could be easily provided by the vtls layer, with the appropriate
backend implementation (GnuTLS seems easy to do but only from 3.x, OpenSSL has
no documentation as usual, but something could be extracted from the openssl
binary, and I don't know about NSS).

I have no idea how to make an HTTP request from inside libcurl during the
certificate verification phase though. Is this actually possible?

Given various comments on the web and in the RFC itself, OCSP doesn't seem much
of a good protocol though, due to performance and privacy issues (e.g. google
chrome disables it by default).

A better and easier alternative to implement would be OCSP stapling (RFC6066
section 8), but it's not very widely deployed AFAICT. Obviously OCSP and OCSP
stapling aren't mutually exclusive.

> wget/httrack -like (and js/css/font/etc -aware) addon in the bundle for
> recursive fetching

I guess this would mean having curl understand HTML?

> easily support [] chars in urls without them being interpreter as a
> range. from the CLI.

Escaping [] (like \[\]) seems to work fine here and the ipv6 issue has been
fixed...

> Curious about latest http/1.1 update in relation to libcurl.

As discussed in a previous thread... haven't looked at this yet.

> Fix the problem where header files became platform/architecture dependent (a
> few years ago), making cross-builds cumbersome even in such a simple scenario
> as building 32-bit libcurl on a 64-bit Linux system. It would seem to be a
> better solution to detect bitness and other platform dependent stuff
> dynamically inside the headers at compile-time. [Sorry if this was sorted out
> since.]

A while ago I made the Debian libcurl dev packages (those shipping the header
files) support multi-arch (i.e. the possibility of installing the same package
from multiple architecture at the same time). This didn't quite work as expected
partly because of the above reason.

I'm planning to move the libcurl headers from /usr/include to
/usr/include/<gnu_triplet> but if this could be solved on the libcurl side it'd
be better I guess.

Another problem I've encountered is that curl-config changes based on the
architecture it was built on because it embeds the libdir paths (which on Debian
change from arch to arch because of multi-arch). The --configure option is also
different. Not sure how this could be fixed though.

Cheers

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html