These days I needed the error code from the HttpClientCurlDelegate and could not get it (it was always 0) and that was because in the function execute of the HttpClientCurlDelegate the error code was not sent to the thrown HttpClientException.
I know that we can extend the classes and have this happen without this fix, but I believe it's more appropriate to have the correct functionality by default rather than needing to do 'extra work' for that.

I will provide the patch below.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

lhangea’s picture

Patch for this issue

lhangea’s picture

Status: Active » Needs review
Bhanuji’s picture

Issue summary: View changes
John Franklin’s picture

That code is normally the HTTP response code (401, 403, 500), and not the errno from curl. IMHO, giving that error code two meanings is bad design.

There are three other places this Exception is thrown: when unserializing a response that is not well-formed; and twice in a long committed, but never released piece of code that is parsing the response from a proxy. In all those cases, the response code is left 0.

This is called in the delegate, which is not accessible to the code using HttpClient, so saving the errno won't work.

The right thing to do is to throw a different exception, say HttpClientCurlException, with the curl error in it. We can make this Exception extend from the HttpCurlException to maintain backwards compatibility and not require a major number bump.

@lhangea, what do you think of this? It has been six years since you posted this patch. Does the site where you needed this still run Drupal 7?

John Franklin’s picture

Status: Needs review » Needs work

Marking "Needs work" until we can figure out a better solution.