I have processed this pull request with some modifications.

1. I removed the strategy as I don't think there is a need for a hierarchy to format an error message. I don't foresee much need to customize it and if that arises it can be solved with a protected method, or even by re-introducing the strategy in the future.
2. There were some backwards compatibility issues. Notably ExtractingResponseErrorHandler was broken because of the overridden handleError with URL and HTTP method, but other signatures needed to be added to preserve existing public APIs.
3. Passing the URL and HTTP method proved problematic and made it more difficult to preserve backwards compatibility, so I've dropped those altogether. While it is nice to include those in the error details I've left that part to be solved separately so this PR can move forward.

Hi,

1 - Makes perfect sense. My use case is a bit specific - in error responses I sometimes need to strip HTML tags (some apps return HTML errors on REST endpoints), sometimes XML (same issue), to see the actual problem.

2, 3 - I wasn't aware of that. Thanks for your input, I'll try to find something suitable.

Thank you.