Upgrade Apache HttpClient to version 4.0 [SPR-6180]

[spring-projects-issues]

Oleg Kalnichevski opened SPR-6180 and commented

Folks,

Please consider upgrading HttpClient to version 4.0 which is the latest stable (GA) version of the library. Commons HttpClient 3.1 is very likely to be deprecated / officially declared end of life very soon (3 - 6 months). There have been no bug fixes in the 3.x branch for over a year.

Patch attached. Unfortunately I was unable to fix the Ivy build which I am not very familiar with.

Oleg

---

Affects: 3.0 RC1

Attachments:

• spring-httpclient-4.0.patch (27.24 kB)

Issue Links:

• 12301 Provide support for Http Client 4 now that it is available ("is duplicated by")

• 11385 CommonsClientHttpRequestFactory getHttpClient() returns HttpClient from Commons HttpClient 3.x which has been EOL'd ("is duplicated by")

• 15356 Request streaming for HttpComponentsClientHttpRequestFactory

Referenced from: commits https://github.com/spring-projects/spring-framework/commit/3690002dce069729e24bb67386df3cbd7655708c, https://github.com/spring-projects/spring-framework/commit/54bbcf3a42ab2be10ebb27b7ff8965dcdf7a5254

17 votes, 20 watchers

[spring-projects-issues]

Oleg Kalnichevski commented

RestTemplateIntegration tests pass for me when using HttpClient 4.0 based implementation of the HTTP request factory.

[spring-projects-issues]

Sylvain LAURENT commented

Any update on this ?

[spring-projects-issues]

Oleg Kalnichevski commented

Arjen, HttpClient 4.1 GA will be released within a week or two. Please consider upgrading to 4.1 bypassing 4.0.

Oleg

[spring-projects-issues]

Roy Clarkson commented

I've implemented Oleg's patch in Spring-Android-Rest-Template as HttpComponentsClientHttpRequestFactory, since Android has no support for the Commons 3.x client. ANDROID-7.

[spring-projects-issues]

John Eckhart commented

I understand adding 4.0 (or even better 4.1), but is there really a need to remove the 3.x support? This will require any project that has implemented HttpClient 3.x and CommonsClientHttpRequestFactory in their app to upgrade the entire HttpClient stack in order to upgrade from Spring 3.0.x to Spring 3.1. I believe that HttpClient 4.x occupies a separate package namespace (and maven group/artifact id) from HttpClient 3.x and the Spring factories for each have separate names. Perhaps it would be better to @deprecate CommonsClientHttpRequestFactory and mark it for removal at a later time?

[spring-projects-issues]

Arjen Poutsma commented

@John: we will do exactly that: deprecate the 3.x support in favor of 4.x support.

[spring-projects-issues]

Arjen Poutsma commented

This has been committed.

Oleg, thanks for the help! Could you please check SVN to see if everything is OK?

[spring-projects-issues]

Oleg Kalnichevski commented

Looks good to me. I wish there was a way to avoid having to buffer request content in memory, though.

Oleg

[spring-projects-issues]

David Parks commented

Not sure if I should comment here or open a new request, but I'll note here first: Any use cases which require an HttpContext attribute to be set aren't covered in this implementation, and the extensions required make the whole thing so messy as to make using the Rest Template more of a burden than a benefit. Here is the particular case that I've been fussing with today to little avail, setting preemptive authentication (i.e. send basic authentication headers by default rather than performing 2 requests to authenticate):

http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html#d4e1023

The problem being that the RestTemplate implementation as it is has no support for setting HttpContext parameters (the template calls the Http.execute(HttpUriRequest) which uses only the non-accessible default HttpContext), there aren't any good way to set the default context parameters on the HttpClient in 4.x Apache HTTP Components. You end up needing to extend HttpClient to provide for default HttpContext params on the HttpClient object and the whole thing just becomes a spaghetti mess from there making the template more pain than pleasure.

[spring-projects-issues]

Arjen Poutsma commented

@David

That's certainly something we can try to improve. Can you please create a new JIRA for this issue, and comment the issue number here so that I can follow up on it?

[spring-projects-issues]

David Parks commented

Added: https://jira.springsource.org/browse/SPR-8367

[spring-projects-issues]

Arjen Poutsma commented

I wish there was a way to avoid having to buffer request content in memory, though.

There now is, see #15356.