#3726 vauth: return CURLE_OUT_OF_MEMORY only in case of out of memory

[dhoelzl]

#3726 vauth: return CURLE_OUT_OF_MEMORY only in case of out of memory; return CURLE_RECV_ERROR in case of other errors

[kdudka]

CURLE_OUT_OF_MEMORY indeed does not make any sense on certain places in the code. On the other hand, CURLE_RECV_ERROR is not always precise either. Would not CURLE_LOGIN_DENIED be closer to the nature of the failures?

[dhoelzl]

You are correct. I have not checked where to use CURLE_LOGIN_DENIED instead of CURLE_RECV_ERROR.
What about CURLE_SEND_ERROR in case of processing a response succeeds, but generating the next request fails?
@kdudka could you please check this? Thank you.

[kdudka]

The problem is that the failure might not be network-related at all. I think that the most common case, which #3726 is about, is just missing credential cache and/or missing Kerberos configuration, which are both local failure.

[dhoelzl]

There are a lot of return codes from gssapi and sspi. Maybe there is a need for a mapping of those error codes to cURL error codes?

[jay]

Maybe it would be better to have a generic CURLE_AUTH_ERROR or something? We seem to have a lot of these and recv error is not entirely correct, though I'm also of the opinion that it's better than an out of memory error.

[kdudka]

@jay I agree. libcurl currently does not have any suitable error code for authentication failures triggered by local environment.

[dhoelzl]

I close this PR, as the based issue has been resolved, and I currently have not the time to investigate deeper into the different error situations / error codes to distinct between CURLE_LOGIN_DENIED/CURLE_RECV_ERROR/CURLE_SEND_ERROR/CURLE_AUTH_ERROR etc. as all the cases probably need to be tested in detail on all platforms.