You will need to modify hc_ResponseSuccess. You can read the headers there.
:sign0161:
So I thought that the httputils2 lib can do digest auth.
Looks unfortunately not so, because I have to implement the whole structure for it.
See this,
Overview
Digest access authentication was originally specified by RFC 2069 (An Extension to HTTP: Digest Access Authentication). RFC 2069 specifies roughly a traditional digest authentication scheme with security maintained by a server-generated nonce value. The authentication response is formed as follows (where HA1, HA2, A1, A2 are names of string variables):
\mathrm{HA1} = \mathrm{MD5}\Big(\mathrm{A1}\Big) = \mathrm{MD5}\Big( \mathrm{username} : \mathrm{realm} : \mathrm{password} \Big)
\mathrm{HA2} = \mathrm{MD5}\Big(\mathrm{A2}\Big) = \mathrm{MD5}\Big( \mathrm{method} : \mathrm{digestURI} \Big)
\mathrm{response} = \mathrm{MD5}\Big( \mathrm{HA1} : \mathrm{nonce} : \mathrm{HA2} \Big)
RFC 2069 was later replaced by RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication). RFC 2617 introduced a number of optional security enhancements to digest authentication; "quality of protection" (qop), nonce counter incremented by client, and a client-generated random nonce. These enhancements are designed to protect against, for example, chosen-plaintext attack cryptanalysis.
If the algorithm directive's value is "MD5" or unspecified, then HA1 is
\mathrm{HA1} = \mathrm{MD5}\Big(\mathrm{A1}\Big) = \mathrm{MD5}\Big( \mathrm{username} : \mathrm{realm} : \mathrm{password} \Big)
If the algorithm directive's value is "MD5-sess", then HA1 is
\mathrm{HA1} = \mathrm{MD5}\Big(\mathrm{A1}\Big) = \mathrm{MD5}\Big(\mathrm{MD5}\Big( \mathrm{username} : \mathrm{realm} : \mathrm{password} \Big) : \mathrm{nonce} : \mathrm{cnonce} \Big)
If the qop directive's value is "auth" or is unspecified, then HA2 is
\mathrm{HA2} = \mathrm{MD5}\Big(\mathrm{A2}\Big) = \mathrm{MD5}\Big( \mathrm{method} : \mathrm{digestURI} \Big)
If the qop directive's value is "auth-int", then HA2 is
\mathrm{HA2} = \mathrm{MD5}\Big(\mathrm{A2}\Big) = \mathrm{MD5}\Big( \mathrm{method} : \mathrm{digestURI} : \mathrm {MD5}(entityBody)\Big)
If the qop directive's value is "auth" or "auth-int", then compute the response as follows:
\mathrm{response} = \mathrm{MD5}\Big( \mathrm{HA1} : \mathrm{nonce} : \mathrm{nonceCount} : \mathrm{clientNonce} : \mathrm{qop} : \mathrm{HA2} \Big)
If the qop directive is unspecified, then compute the response as follows:
\mathrm{response} = \mathrm{MD5}\Big( \mathrm{HA1} : \mathrm{nonce} : \mathrm{HA2} \Big)
The above shows that when qop is not specified, the simpler RFC 2069 standard is followed.
Impact of MD5 security on digest authentication
The MD5 calculations used in HTTP digest authentication is intended to be "one way", meaning that it should be difficult to determine the original input when only the output is known. If the password itself is too simple, however, then it may be possible to test all possible inputs and find a matching output (a brute-force attack) – perhaps aided by a dictionary or suitable look-up list.
The HTTP scheme was designed by Phillip Hallam-Baker at CERN in 1993 and does not incorporate subsequent improvements in authentication systems, such as the development of keyed-hash message authentication code (HMAC). Although the cryptographic construction that is used is based on the MD5 hash function, collision attacks were in 2004 generally believed to not affect applications where the plaintext (i.e. password) is not known.[1][citation needed] However, claims in 2006[2] cause some doubt over other MD5 applications as well. So far, however, MD5 collision attacks have not been shown to pose a threat to digest authentication, and the RFC 2617 allows servers to implement mechanisms to detect some collision and replay attacks.