Its looks like the first GET is challenged and the credentials are provided
but when executing the second GET the authentication is requested for a
different realm but because the AuthState already had credentials they were
used.
The member targetAuthState in DefaultRequestDirector holds the old
On Tue, 2014-03-25 at 09:29 +0200, d_k wrote:
Its looks like the first GET is challenged and the credentials are provided
but when executing the second GET the authentication is requested for a
different realm but because the AuthState already had credentials they were
used.
The member
On Tue, 2014-03-25 at 00:03 +, sebb wrote:
On 24 March 2014 23:01, Christopher BROWN br...@reflexe.fr wrote:
Hello,
This article:
http://blog.lunatech.com/2009/02/03/what-every-web-developer-must-know-about-url-encoding
...refers to the pitfalls of using Java's standard URLEncoder
On Mon, 2014-03-24 at 21:09 -0400, Nick Chang wrote:
Hello,
We are using httpclient to build a web proxy application in our product. We
use 4.2.3 version and it has been working flawlessly. Now I am trying to
migrate the product's httpclient library from 4.2.3 to 4.3.3 to achieve
Thank you very much for the support. :-)
So it appears that upgrading httpclient won't solve this issue?
On Tue, Mar 25, 2014 at 11:27 AM, Oleg Kalnichevski ol...@apache.orgwrote:
On Tue, 2014-03-25 at 09:29 +0200, d_k wrote:
Its looks like the first GET is challenged and the credentials
Alright. Thank you very much for the help!
Currently JIRA (https://issues.apache.org/jira/browse/HTTPCLIENT) is down
for maintenance but i'll open an issue when its back online.
On Tue, Mar 25, 2014 at 12:02 PM, Oleg Kalnichevski ol...@apache.orgwrote:
On March 25, 2014 10:55:20 AM CET, d_k
It seems that using the different constructors (encoding, decoding) of
java.net.URI helps in most cases I have to deal with (for example I can
pass it one directory in a longer path with encoded characters to the
single-String constructor to decode, or use multi-parameter constructors
for
