1

As you can see the Apache httpclient 3.x had an amazing method that you could use to reduce the amount of unnecessary connections and data that is send around between client and server:

client.getParams().setAuthenticationPreemptive(true);

http://hc.apache.org/httpclient-3.x/authentication.html#Preemptive_Authentication

What I want to know is, why did they remove it?
I know there are proper workarounds like using an interceptor or modifying the header, but I am wondering about the reasons behind that change: stability, performance, security, conformity? ...

ASA
  • 1,911
  • 3
  • 20
  • 37
  • You should ask *them* ... – Stephen C Nov 26 '13 at 14:55
  • 2
    I guess I qualify as _them_. If the question gets re-opened I could answer it. – ok2c Nov 28 '13 at 09:25
  • I am assuming there is such a thing as a mailing list for Apache developers. I would recommend asking this question there. This question on StackOverflow is bound to attract answers from people who *think* they know the answer, or do a wild guess, without actually knowing the reason. I doubt there is much documentation about why something was removed to base answers on either. I think the question can better stay closed. – Sumurai8 Nov 28 '13 at 09:52
  • @Sumurai8: Believe me, this question was answered on the user list on more than one occasion. – ok2c Nov 28 '13 at 10:03
  • I can imagine removing a very comfortable and clever feature that can increase performance with one simple boolean on the assumption that relevant parts of the user base are simply too stupid to use it safely is controversial. And I guess lots of people are now using the workarounds without even knowing about the background that you explained here. – ASA Dec 05 '13 at 09:56

1 Answers1

2

Preemptive authentication as a simple boolean flag is a good example of how features got added to HC 3.x without long term considerations until the 3.x codeline became a completely unmanageable mess.

Prevention of accidental sensitive information disclosures was the main reason for changing the way preemptive authentication works in HC 4.x. HC 3.x made it exceptionally easy for people to submit their credentials to random sites in clear text without even realizing that.

As of 4.1 HttpClient employs a much saner strategy by default: authentication credentials get cached in the execution context after an explicit authentication challenge and a successful authentication. All subsequent requests in the same session are authenticated preemptively using cached authentication material. One can still force preemptive authentication of the initial request by pre-populating the auth cache if necessary. But at the very least that requires that the user explicitly provides auth material for a specific auth target.

ok2c
  • 26,450
  • 5
  • 63
  • 71
  • Thank you for your answer. But how can this even happen? Does it happen if you reuse a client object with preauth on and change it's target address? – ASA Dec 03 '13 at 08:37
  • 1
    @Traubenfuchs: HttpClient should be shared and re-used, often by different threads representing different user identities. More often than not users of HC 3.x used to turn on preemptive authentication without thinking simply because they heard someone say it should improve performance. – ok2c Dec 04 '13 at 20:51