https://sourceforge.net/p/curl/feature-requests/70/

From IRC:
<Nach> Bagder: would you at all be interested in a patch that implements Digest Auth with qop=auth-int, which does so in an unorthodox manner?
<Bagder> Nach: I think it depends on what exactly that means! =)
<Nach> Bagder: one would need to pass the MD5 of the data to be sent via curl_easy_setopt() in advance or similar
<Bagder> Nach: ah, because it needs to be known before-hand, right?
<Bagder> I mean, in the request
<Nach> Bagder: that is correct
<Nach> and that's what I do in my franken-curl lib we use at work...
<Bagder> Nach: I think I could be fine with that, assuming we just document how to do it as a user
<Nach> okay
<Nach> Bagder: curl_easy_getinfo() could also use an ability to have it check to see if server returned Authentication-Info header, and if so, if it was valid
<Bagder> Nach: yes, makes sense

The first step towards supporting Digest Authentication with
qop=auth-int (integrity) would be to give libcurl a way to access
minimally a hash of the data upfront. To that end, libcurl needs some
options for specifying the hash of the data.

I added two options CURLOPT_CONTENTHASH and
CURLOPT_CONTENTHASH_FORMAT. The former is a pointer to the raw hash
data. The latter is a C string specifying what format the hash is in.
Currently the only recognized value is "MD5".

I chose this flexable design, for four reasons.
1) Giving access of a hash of the data opens up a lot of possibilities
for future work. Different protocols will allow for different hashes.
2) MD5 is currently used multiple places in HTTP. Content-MD5 (RFC1864), as well as with HTTP Digest Authentication (RFC2617).
3) RFC2617 technically allows for other hash methods to be added,
although no typical browser or server does so. However, it is expected
that later standards will officialy add support for other hash formats
(http://tools.ietf.org/html/draft-ahrens-httpbis-digest-auth-update-00).
 Right now, some custom implementations. and even some VoIP boxes I've
seen in the past support the SHA family too.
4) When using Dighest Authentication with qop=auth-int and sending a
Content-MD5 as well allows for the server side to parse the headers and
determine access immediatly, and correctly issue a 100-continue, without
 needing all the data to determine if the user has access. Technically a
 server allowing qop=auth-int with a large Content-Length without
Content-MD5 being present makes it an easy DoS target.
Therefore, this patch allows one to specify to libcurl a hash of the
data that will be uploaded. For HTTP, if a hash is specified, it will
also add a Content-MD5 header to request headers.

I'm breaking my work up into multiple self contained steps, so it's
easier to review and document, unlike monolithic patches. Also, I
imagine the cURL developers might want to make some tweaks to my current patch, so I'll wait for this patch to be finalized and see how things
are structured before I continue working on backporting auth-int support from the custom "franken-curl" I use.

My tarball includes the following:
A diff against 7.30.0 to add on the above.
A simple PHP server side script for my testing of Content-MD5.
A simple C application using this patched libcurl to upload data via PHP POST to the above script.
A log of compiling and running the C application which shows correctness.

Please share with me your thoughts.

-Nach

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